Feature request: project root

[nikklassen]

It would be nice to put a file in a directory so that I could do prm start without arguments anywhere under that directory and the appropriate project would start. This file could also indicate the base directory for relative paths in start.sh and stop.sh.

[EivindArvesen]

Sorry for the wait.

From how I imagine this feature (and its hypothetical implementation), I think it would greatly increase complexity, and complicate maintenance. I can, however, imagine possible gains from it.
Therefore, I'd like to fully explore both the idea itself, as well as any possible alternatives before committing to anything.

1. If I understand you correctly, you would like to use prm in the same kind of way that e.g. git works, right?
2. And with regards to indicating the base directory for relative paths [...], do you mean something like setting this in a custom environment variable?
3. Do you imagine this as something dependent on the current way prm handles projects (i.e. inherently linked to the central project list), or as a way to support portable projects?
4. What would this solve that the way prm currently works doesn't, or that a shellscript in your project directory doesn't? Is there an example or a hypothetical situation that clearly illustrates this?
5. Do you have any suggestions as to how (parts of) a solution would work, i.e. implementation details – in (pseudo)code or in plain english?

I'd also appreciate anyone else's thoughts on the proposed feature.

[nikklassen]

I'll try to expand on what I meant in the hope that it will address some or all your points. But first, if what I'm suggesting is not aligned with the vision you had for this project then by all means keep it the way you're doing it now. I like the utility and it's certainly handy the way it stands. Maybe you could tell me a bit more about why you chose to have a global list of projects.

The way I see myself using this application is similar to how you would use a build system or version control. When you call grunt or npm (I do this most often in the JS ecosystem), all of these applications search upwards to find a directory containing a .<app name> file (or something similar), and use that directory as their base. So if I was in directory a/b/c or a/b and my root was in a then I could do prm start and it would find the dotfile and start the project located in that file. That way if I have sshfs remote:some_dir mntpoint in my prm-start.sh then I know the directory will always be mounted at a/mntpoint. Without this feature I have to make sure I always start in my root directory, which isn't so bad, more of a convenience. What I see as the more attractive result of this decision is that you don't have to tell prm which project you want to run, you just run prm start (helpful if you have lots of projects and forget the name). A project configuration could be implemented as simply as

.prm contents:

project=my_project

Search

while [ ! -e .prm ] && [ $PWD != ~ ]
do
    cd ..
done

Basically, I think local project configuration is easier for the user to manage than global projects.

[EivindArvesen]

TL;DR: Supporting portable projects and possibly allowing the central project list to link to these can possibly solve your problem, and more.

The details you describe certainly makes sense, and are just about how I imagined them while reading your first post. But, from what I gather, this kind of use would arguably remove the management-part of the application, and leave only the environment automation.

While your suggestion might not line up exactly with my original intentions for prm, I do see value in what you're suggesting – and should it seem best, I would have no issue with adjusting my vision so that it includes this functionality.

Why a global list of projects?

The main reason for choosing to have a global list of projects was so that I would not have to remember the paths of the various projects I was working on, as these are basically all over the place.
Here are some examples:

• ~/src/Bash/prm
• ~/Library/Application\ Support/Sublime\ Text\ 3/Packages/Xkcd
• ~/src/LaTeX/MasterWritings/thesis
• ~/Documents/School/Masters/1year_12-13/spring/Machine_Learning/Notes

The way prm currently works, I cd to the project paths in my start-scripts, and don't have to memorize anything. This (i.e. motivations, design goals, etc.) should of course be documented better (in the Wiki), but alas, I have not gotten around to it yet (#19).

The way this is currently implemented, on the other hand, is more or less happenstance.
I have been pondering an alternative implementation as of late that would enable portable projects, e.g. projects distributable in version control.

A possible solution

I would have no issue with enabling support of local projects, in fact I think the flexibility it would enable is good in and of itself. I do think, however, that this needs to be discussed more.

This is what I'm currently thinking:

• Issuing a bare command, i.e. prm, could attempt to find local projects in the way you described – if none are found, prm falls back to its current behavior (i.e. help-screen); and
• Global projects could (optionally) be links to projects defined elsewhere, either:
  • via a dotfile .prm (as you suggested); or
  • via having a folder .prm/in the project root that contains start- and stop-scripts, etc.

As far as I understand, this would enable you to use prm in the way you propose, as well as enable portable projects. I'm not sure the dotfile is needed for the purpose of setting a project root though, as this can probably be deduced from its location anyway.
However, this is all just from the top of my head, and there is likely issues with logic and/or complexity here.

Going forward

The implementation details needs to be more or less completely ironed out before any code is committed, and this (in addition to the current functionality and the originally envisioned usage) must be thoroughly documented.
It should probably also be divided into several smaller issues and tasks.

I'd also be very interested in what @FredDeschenes thinks about all this.

Sorry for the wall of text!

[nikklassen]

I hadn't considered the use case of launching projects without having to visit them first. I understand your motivation for using this as a system-wide project manager. It's certainly different than how I thought of using it as a manager for individual projects. The first idea I have is to keep the system-wide feeling is to create mapping in some file, say ~/.prm such that prm start <proj> would jump to that project location (or wherever you want), then run the start script, whereas `prm start`` searches up. That seems to satisfy both use cases.

[EivindArvesen]

The problem is that there are use cases where one might not want to change directories, which is why this is not implemented as a feature, but rather left up to users to perform in their project start-scripts. There is therefore no such thing as an inherent project location.

In addition, I don't think breaking backward-compatibility is a good idea, which would be the result of what you're suggesting (if I understand correctly, and you mean that the mapping-file should replace the current way entirely).

Pertaining to the portable project support I mentioned earlier, I was thinking more in the sense of implementing additional functionality in prm that lets it "import" or link/map to project-scripts outside of the central data folder. This approach would also have the advantage of being fairly straightforward with regards to how prm currently manages active (i.e. running) projects and performs cleanup.

[EivindArvesen]

@nikklassen : Stumbled across Swissknife, and thought of you.
What we've discussed in this issue is still on the table, though.

[nikklassen]

That looks interesting too.