Command & target re-use

[mingan]

I've been playing around with Sup and it's elegant and simple, but I'm hesitant to use it as a deploy tool for our projects because I miss re-use options.

I created a Supfile with around 200 lines as a prototypúe. It does pretty much everything that I expect it to do (and few things on top of it), but it's tailored to one service. But I have eight different services. Some aspects of the deployment process should be identical (except for some names), e.g. directory and file structure setup, compilation, Slack notification, some are different or not used in all cases, e.g. upload of some config files. I'd like to re-use the identical steps (and preferably sequences of steps) between the different services.

As far as I can tell, the only way to somehow achieve it (apart form copy & paste) is to use multiple Supfiles and call the shared one from the project-specific one. However, I don't see any way to only define networks in the project-specific one which kinda makes sense but how do I achieve some level of re-use? I really want to avoid copy & paste.

[VojtechVitek]

Good points. Thanks for raising this. Do you have any potential solutions in mind?

[mingan]

In order to solve my use case, I'd like the option to import one Supfile into another, going directly against

Supfile doesn't let you import another Supfile.

In my mind, 80:20 solution would be to import commands from one Supfile into another so that I can invoke command from the imported one by running the latter. The command would be executed in the context of the importing Supfile (with its network and variables).

There are several obstacles I can see immediately:

1. How to deal with name collisions? My instinct is to let the importing Supfile take precedence but I can imagine arguments against it. Alternatively one of the simpler approaches would be to name each imported Supfile and prefix the command use by it.
2. How to deal with recursion - pretty much depends on the previous issue.
3. Should it be possible to import multiple Supfiles, what about their order and conflicts?
4. Should some/all variables be imported. If yes, how to deal with name collisions?
5. If anything like this was implemented I'd like to see a subcommand which would show me where each command/variable comes from.
6. Assuming the same structure, the targets and networks sections of the imported Supfile would not be used at all. That might be a bit confusing but defining another format "importable Supfile" to signal the intent seems like an overkill.

There are probably even more issues I can't think of right now. My question is if anything like this would be welcomed at all. Admittedly, I might be an outlier with this need and I can see that such a feature could easily balloon up and create unnecessary complexity.

[VojtechVitek]

We heard people asking for reusable networks/hosts too and that's why we came up with "inventory".

Yeah, you raised good points. This can easily grow out of scope to a very complex solution with lots of edge cases.

I wonder what the rest of the community thinks about this. Or if they have any other elegant solutions in mind..

[mingan]

Thinking about, you're right. In our current state, we'd probably reuse networks as well. I'm wondering about input from others, this seems like a thing every other user would use.

definitions are already cascading, so the last definition takes precedence, targets just fetch the defined commands so they will follow.
If a sourced Supfile has collission with another Supfile then those collissions should be dealt with by who made the Supfile, sup should at best print a warning about redefining an already defined config.
I think expected behaviour is already present and its just a matter of adding the parsing capability