conda-pack
conda-pack copied to clipboard
conda
Remove missing files from the file list.
@xhochy can you revisit this one? I'm afraid there are some nontrivial merge conflicts now. In particular, note that I created a setup_envs.bat for Windows that mirrors setup_envs.sh for Unix because I was having issues with bash on Windows.
Now that we're using GitHub Actions for CI you can just delete .travis.yml. And setup_envs.bat is gone again, too; we're now back down to just setup_envs.sh. So it should be easier to merge your changes.
Now that I've spent so much time wading in this, I'm actually going to propose the following: that conda pack should always be tested against its own conda installation—or more specifically, its own package cache—so that it's free to manipulate that cache however it wants to without distrupting the user's local installation.
That's effectively what I do in the GitHub Action. For the raw package build and the doc build, I'm using the worker's built-in Miniconda install. But for the testing, I'm installing our own conda environment.
That said, I'd rather not do a full conda clean in testing. Let's just delete one or two packages, like the current testing does.
It doesn't even matter, actually, if the conda used to create the environment is the same as the conda used to run the test! Because the code determines the location of the cached packages by the metadata in the environment.
OK, with https://github.com/conda/conda-pack/pull/135 I've changed the testbed in a significant way: it now creates a full conda tree, including a root environment with conda installed, and with that conda installing the individual test environments. This is significant because it enables the testbed to control its own package cache without disrupting any other work the developer might be doing.
So with this, we can free free to remove package cache entries at will, as we now do with the Python 2.7 version of the conda_pack_test_lib2 package.
