Add ability to build a different package than project's main about uberenv

[chapman39]

I think this would be useful. I personally forget to add the "%" sometimes in --spec sometimes so we should make it obvious to the user that we aren't building the project package.

Also on that note, what if the user does do --spec=<project_package> without the "%", with this update?

While this issue is 3 years old but it does relate to #11.

[adrienbernede]

@white238 I would like to know more about the use case here.

I understand what you guys want, but I wonder if this is good for uberenv. It’s meant to be a specialized wrapper that sets spack up and builds you projects dependencies.

If we add the ability to install any package, it becomes a Spack wrapper: we can install anything and we may get used to rely on Uberenv instead of Spack, with several risks:

• Wanting to add support for more and more options from Spack we don’t currently need. "Hey, since we can install anything, it would be good to be able to call spack find to list all the specs we have", "Oh, and I’d like to be able to remove packages too".
• Adding complexity to the script. The current implementation, just got simpler thanks to @chapman39, but adding the ability to install any package may require an entirely new path in the script. The evil is in the details.
• Conflicting with the core feature. I think installing a specific spec would have to be done outside the environment, otherwise the spec is added to the environment, correct ? I’m rusted with environment, but what I mean is that I’m not sure it’s as simple at it seems to keep things straightforward (and maintainable) in terms of implementation.

My alternate suggestion (or question) is: What’s the problem with using the Spack set up by Uberenv to manage your additional packages? It’s there, set up with your controlled configuration, it may require you to set some env variable to be isolated (how about that spack command wrapper @kennyweiss wanted uberenv to generate?).