Is your feature request related to a problem? Please describe.
We make our projects with childproject init [folder] at a given time, and are expected to use the Conda environments as we find them under ChildProject/env_macos.yml. This is our main form of package management.
I find we have two main issues with regards to package management:
- Minor: we are missing exact versioning, which might be a problem for reproducibility. That is, we don't "lock" our environment, I think is the jargon (in the poetry package manager, for instance, you have the
poetry.yaml and poetry.lock file, where the lock file derives from the yaml, and gives the most-specific-as-possible description of the virtual environment)
The consequence is that our conda environment installed at a later time or on a different system might give different package versions, meaning our code could break or give inconsistent output.
- Major: we are making ChildProjects projects and relying on ChildProject for our scripts. However, we do not keep track of the version of ChildProject that these scripts are expected to use. That means when we make a backwards-incompatible change to ChildProject it is possible for these scripts to break. I think this is quite important if we are to make significant changes to ChildProject moving forward.
Since we are like the only consumers of ChildProject, we can for the moment, provision our repos with this information in "not too much time".
Describe the solution you'd like
This is one solution:
Fundamentally we need to link the virtual environment (conda env) not with the repository as a whole, but with the project, that is to say on a per-project basis. The version of ChildProject also needs to be specified in the project-specific conda env. One way is to have a command like ChildProject activate that activates the conda environment for the project.
https://github.com/conda/conda-lock this might be useful to us, and has approval from the conda steering council.
Is your feature request related to a problem? Please describe.
We make our projects with
childproject init [folder]at a given time, and are expected to use the Conda environments as we find them underChildProject/env_macos.yml. This is our main form of package management.I find we have two main issues with regards to package management:
poetry.yamlandpoetry.lockfile, where the lock file derives from the yaml, and gives the most-specific-as-possible description of the virtual environment)The consequence is that our conda environment installed at a later time or on a different system might give different package versions, meaning our code could break or give inconsistent output.
Since we are like the only consumers of ChildProject, we can for the moment, provision our repos with this information in "not too much time".
Describe the solution you'd like
This is one solution:
Fundamentally we need to link the virtual environment (conda env) not with the repository as a whole, but with the project, that is to say on a per-project basis. The version of ChildProject also needs to be specified in the project-specific conda env. One way is to have a command like
ChildProject activatethat activates the conda environment for the project.https://github.com/conda/conda-lock this might be useful to us, and has approval from the conda steering council.