-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: project root #20
Comments
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.
I'd also appreciate anyone else's thoughts on the proposed feature. |
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 .prm contents:
Search while [ ! -e .prm ] && [ $PWD != ~ ]
do
cd ..
done Basically, I think local project configuration is easier for the user to manage than global projects. |
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.
The way prm currently works, I The way this is currently implemented, on the other hand, is more or less happenstance. A possible solutionI 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:
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. Going forwardThe 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. I'd also be very interested in what @FredDeschenes thinks about all this. Sorry for the wall of text! |
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 |
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. |
@nikklassen : Stumbled across Swissknife, and thought of you. |
That looks interesting too. |
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.The text was updated successfully, but these errors were encountered: