Project extendibility

[EivindArvesen]

Support creation of common modules/tasks that can be used across projects.

Could be solved by implementing a loader-function in prm (which would be automatically available in projects) that loads "$ARGUMENT.sh" from a reserved folder~~, and appropriate commandline args for manipulating these modules~~.

[FredDeschenes]

I think this would just add complexity in the tool for a small feature gain as users can already have common commands in separate scripts and run/use them from their start/stop scripts (unless I'm misunderstanding the feature).

Anyway, I'll implement this in prm-fish if you add it here.

[EivindArvesen]

I was thinking of something along the lines of plugins/templating.

Lets say prm exposes the currently active project via a variable $PRM_ACTIVE_PROJECT.
Something like

prm_load 'my_python_activation' $PRM_ACTIVE_PROJECT

in a project start-script would load my_python_activation.shfrom a reserved path, e.g. $PRM_PATH/.modules.

The my_python_activation.sh module could be something like

# activate conda env (python)
source activate $PRM_ACTIVE_PROJECT

# count outdated packages
echo "$((($(conda search --outdated --names-only | wc -l)-1))) outdated packages in env"

# ...

, which could be useful if you often create similar projects or use the same tools for projects of a certain language.

Was this how you understood my original comment?
I certainly see your point about added complexity and a small gain, though.

[FredDeschenes]

Oh so basically project templates then? I guess that could be useful.

We would probably have to remove the 'multi-project' feature for 'add' though, as we wouldn't really be able to differentiate between 2 projects being specified or a project and a template name. Ex:

# prm add someproject someotherproject
# prm addfrom sometemplate someproject

We could also add a copy function that copies a project, which would allow pretty much the same functionality (ie: have a python-base project that you copy and edit).

[EivindArvesen]

I was thinking more about project templates in the dynamic sense, as separate scripts that can be loaded from any project's start- and stop-scripts.

But it would, like you say, add complexity.
I think a sensible option might be to implement a loader-function, but drop the proposed args for manipulation, though I need to think more about this, and would like to see more discussion.
It certainly goes on the back burner for now.

The copy functionality you mentioned sounds pretty handy, though – regardless of what I'm talking about. I'll open a new issue for this, and mention you.

[stanimirovv]

This is going to be a long post, so bear with me.

I like the idea of reusability, although I think that project templates are a hard thing to implement given the diversity which projects have.
My proposition is to use hooks. Here is the basic idea:

1. Have a special directory in prm which holds the "reusable" scripts. (This directory should be stored in an environment variable)
2. Before every start/stop/whatever command of prm, prm loads it's configuration file, that way setting the environment variables it will use.
   (Note: as far as I know currently prm doesn't have a configuration file, so it's probably time for it to start having one regardless if we go for this or not)
   For every action of prm (start,stop) there will be a couple of points where an extra script can be executed if it is set in a corresponding envvar.
   In particular before or after the execution of the start/stop script. That way the reusable part can be in the hook, which will be executed before or after the project-unique part.

So, basically for this to work we need to have a directory in which we look for scripts to load (we don't have to have it, but it's good to have a place where all the scripts should be kept)
And to add 2 checks per command if an envvar is set, if so, try to execute the the file it leads too.

The way I see it, this should give enough freedom, without making things too complicated from the maintenance point of view.
There are probably things I am missing, so I am looking forward to hearing what you guys think about this.

[EivindArvesen]

This is more more or less what I had in mind, except that – if I understand correctly – the solution you propose would limit the available custom scripts to one, which would mean that one would need several config-files, or to edit one config-file.

Don't you think it would be better (as in giving users enough freedom, and making it easy to implement) to just allow users to source in a custom script (from a special directory) by passing its basename (minus extension) to a loading-function?

This way, users can choose at which point (during start- and stop-phases) to load their scripts, and all custom scripts would be available at all times.

[stanimirovv]

I think what you have in mind is the better solution and we should go with it since it will offer more freedom.

[EivindArvesen]

Great!
I'll probably implement this relatively quickly.