Skip to content
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

Allow for the creation of multiple environments with custom names #359

Closed
goanpeca opened this issue Aug 22, 2020 · 14 comments · Fixed by #509
Closed

Allow for the creation of multiple environments with custom names #359

goanpeca opened this issue Aug 22, 2020 · 14 comments · Fixed by #509
Labels
locked [bot] locked due to inactivity type::feature request for a new feature or capability

Comments

@goanpeca
Copy link
Contributor

goanpeca commented Aug 22, 2020

Would it be possible to update constructor to do something like this:

name: Uberconda
version: 1.0
install_in_dependency_order: True
channels:
  - http://repo.anaconda.com/pkgs/main/

specs:
    - python 3.5*
    - conda

envs:
  - name: something_else
    specs:
    - python 3.5*
    - numpy
  - name: _something_private
    specs:
    - python 3.5*
    - pandas

license_file: EULA.txt

# Welcome image for Windows installer
welcome_image: bird.png                  [win]
@goanpeca
Copy link
Contributor Author

Pinging @nerohmot and @scopatz

@mcg1969
Copy link
Contributor

mcg1969 commented Aug 27, 2020

Already working on it! #356

@goanpeca
Copy link
Contributor Author

goanpeca commented Aug 27, 2020

Hi @mcg1969, thanks for the feedback.

It seems that PR is allowing to create multiple installers with a single environment on one go. Did I get this right?

What I am asking for is the possibility of having an installer that will create several environments, not just a base one.

Thanks!

@mcg1969
Copy link
Contributor

mcg1969 commented Aug 27, 2020

Oh I see, that's different! Sorry for the confusion

@mcg1969
Copy link
Contributor

mcg1969 commented Sep 6, 2020

Thinking about this more, this would definitely be possible but quite challenging. Here's what it would need to do:

  • Run the conda solver on each environment and collect the package lists for each.
  • Merge and deduplicate into into a single package list. Use this list to build the package cache blob.
  • Use single --extract-tarball and --extract-conda-pkgs to unpack the resulting package cache
  • Create multiple conda install commands, one for each environment.

These would need to be done for all installer types. I'm not inclined for us to build something here that is unique to Unix, say.

Open questions:

  • One pre_install per environment, or one per installer?
  • One post_install per environment, or one per installer?
  • How to differentiate between root and child?

@goanpeca
Copy link
Contributor Author

goanpeca commented Sep 7, 2020

Hi @mcg1969

this would definitely be possible but quite challenging.

🤷 🙃

These would need to be done for all installer types. I'm not inclined for us to build something here that is unique to Unix, say.

Agreed.

The idea of a 1 click installer is something I want to make happen (sooner than later) for projects like JupyterLab. I want to have the actual applications be installed on "private" envs _jupyterlab and provide a safe update path and way for installing extensions and additional kernels, and also connecting to any other envs in the system.

This idea initially requires having at least 2 envs, a base one and the application one _jupyterlab

One pre_install per environment, or one per installer?

I would say per installer since am installer acts as a whole, just that it is using more than 1 environment to handle different things.

One post_install per environment, or one per installer?

Same as before

How to differentiate between root and child?

In terms of what?

Thanks!

@mcg1969
Copy link
Contributor

mcg1969 commented Sep 7, 2020

At least one of the environments in the list needs to be the root of the installed environment tree. So how do we specify that in a case like this?

@goanpeca
Copy link
Contributor Author

goanpeca commented Sep 7, 2020

In the example I gave above #359 (comment)

I added a key called, default, it could be base or root or similar, and there could only be one set to True.

@mcg1969
Copy link
Contributor

mcg1969 commented Sep 8, 2020

That works!

@goanpeca
Copy link
Contributor Author

goanpeca commented Sep 8, 2020

Thanks @mcg1969 :-), please let me know in any way I can help. Also my suggestion was really a quick idea, not thoroughly designed, so take with a grain of 🧂

@mcg1969
Copy link
Contributor

mcg1969 commented Sep 8, 2020

Well to be clear, this is not something I personally am going to be able to implement—so if you or anyone else wants to take a crack at it, please do! I am happy to offer reviews and guidance.

@goanpeca
Copy link
Contributor Author

goanpeca commented Sep 8, 2020

I would like to hear more use cases, I have a very specific one in mind :-)

Any guidance is also welcome so I could also tackle this at some point 🤷

@mcg1969 mcg1969 added the type::feature request for a new feature or capability label Sep 27, 2020
@goanpeca
Copy link
Contributor Author

@jaimergp

@jaimergp
Copy link
Contributor

Hey folks, this feature has been implemented in #509 if you want to take a look!

@jaimergp jaimergp moved this to Done in 🧭 Planning Aug 12, 2022
@github-actions github-actions bot added the locked [bot] locked due to inactivity label Aug 13, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked [bot] locked due to inactivity type::feature request for a new feature or capability
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants