[Feature] to select from different plans at build

[ShalokShalom]

@bdangit brought up an important aspect of studio management in combination with team collaboration, IMHO:

When different team members create their studios in different directories levels at their SCM structure, will this lead to a confusing situation with potentially unnecessary additional work stages.

You can avoid that, by hab studio enter in the highest possible directory and there is only one issue, he sees doing that: You can't just type build, you have to type build /path/to/plan.sh for each package.

So, the idea is, to implement an autodetection which build runs, before it does something else.
This detection looks if there is more than one plan.sh in the directory tree and if yes, does it read all the different pkg_name= and display them for selection.

This here is a similar thing in Pacman, just imagine the first line as build and the output as the different package names:

a) This makes it more clear to new users, where to create their studio.
b) It improves the cooperation between humans who work on the same project.
c) It is in general useful

[skyvine]

Hello,

I am interested in working on this issue; it would be my first contribution to Habitat. I've cloned the repo and started digging through the code, but I'm having some problems figuring out where to start. In components/hab/src/command/studio/mod.rs it seems to be invoking the hab-studio program, but it's not clear to me where I would find the source for that command if not in the studio module under the hab directory tree. Any assistance you could provide would be appreciated.

Thanks,
Bryan

[reset]

@SaffronSnail the actual studio is implemented in bash for Unix platforms and powershell for Windows. You can find them here and here

[skyvine]

@reset Thanks for the links! I've implemented a couple of rust functions which I believe do the majority of the work required (one searches a directory tree for a file with a particular name, the other is responsible for managing the prompt). It looks like you're using the PLAN_CONTEXT environment variable to keep track of what directory the plan is located in, so I'll look into how that's getting set in order to integrate them with Habitat.

[skyvine]

Sorry for the delay; I was having some problems building the project, but I've set up an Arch installation that seems to be working fine.

After spending some time digging through the files, it seems like the most logical place for me to call my code is from the scripts, rather than from Rust code (which surprised me, since this issue is labelled L -Rust). In particular, on Linux I want to call the code at line 3000 of hab-plan-build.sh and line 1228 of hab-plan-build.ps1. However, I am hesitant to do it this way because it seems to run contrary to the way Habitat is deisgned; as far as I can tell, all of the code has Rust functions calling scripts, not the other way around. Am I correct in my analysis?

There's also a related issue I want to discuss. A few lines above (in both files) there is a check to make sure that both plan.sh and habitat/plan.sh do not exist. Do we still want to do this check? I can see an argument in favor of it, because I would expect that 'normal' usage would involve having one plan in either location. However, I could also see an argument against it; the comments in the script say that the check is done to avoid confusion if a developer modifies habitat/plan.sh but the program builds based on ./plan.sh (or vice-versa). With this functionality it would be clear to the developer that both files exist and they could simply select the right one. That being said, I can't think of a good reason why you would want two "default location" plans, as it would seem to lead to more confusion than anything else.

[bdangit]

does it make sense just to make some kind of bash auto-completer that when there's a hab build doing double tab would display what plans are available to build?

[skyvine]

I could see an argument for that, though I don't know if it's possible to do so in powershell. Based on this article it's not, though I haven't done extensive research and I haven't worked with powershell in the past, so take my words with a grain fo salt.

I think the main point in favor of using auto-completion is that it integrates more cleanly with the scripts that implement the studio. Against it is code duplication and that, in my opinion, double-tabbing is less ergonomic than having the system prompt you. I don't think any of these are strong points however, so I'm fine with going in either direction (assuming that it is possible to replicate the functionality in powershell).

[ShalokShalom]

@SaffronSnail Thanks for implementing this.
It makes me happy to see when an issue report results in an actual improvement. :)

[skyvine]

@ShalokShalom Sure thing, but it's not done yet!

If no one has any objections, I'm going to upload the functions I wrote as a package in habitat, add it to the list of dependencies in hab-plan-build, and invoke it from the script. This seems to be the path of least resistance.

[ShalokShalom]

Sounds fine.

[skyvine]

Sorry for the silence on this issue; I have been delayed by a combination of life events and problems building Habitat on NixOS. I've sorted through everything though and I'm getting back to it!

[ShalokShalom]

All fine, thanks a lot. :)

[skyvine]

Alright, so I think I have the required functionality implemented, I just have a few issues to resolve. You can see the rust utilities I created on this repo and you can see the modifications I've made to components/plan-build on this repo. The issues I need to resolve are the following:

1. I need to convince habitat to actually use my modified script in order to test it. I have made sure that the script works by itself with a gnu-hello plan, but that was invoking the script from the command line.

2. I need to document the rust code.

3. I need to modify the utilities to use clap instead of hand-written command line parsing

4. I need to modify the powershell script so that this feature is available on all supported systems (I expect this to be trivial once the linux side of it is working fine).

[rsertelon]

@SaffronSnail Do you still pursue work for this issue? if you do not, please tell us so that someone else could do it if not ;) thanks!

[skyvine]

@rsertelon I submitted a pull request here that I believe resolves this issue. As far as I know, there's nothing for me to do unless the pull request is rejected for some reason. But if there are any issues with it I would be happy to fix them.

[rsertelon]

Oh, I didn't see it! Would you mind having a look and see if you could rebase it? Then I could ask core maintainers to have a look, this is an interesting feature. Plus, it might be helpful for core-plans and people who have lots of plans in the same repo :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.