or check te files in conda-meta
I work in academia and we're trying to figure out a backup policy that lets us skip backing up conda while still preserving the info needed for users to recreate their environment if need be. We don't want our backup scripts to su to the user to run conda stuff.
that's assuming miniconda but i guess it's probably similar for other install methods
you could write a shell script to parse the package name out of the filename
Note that --override-channels means that no additional channels are searched for dependencies. Since bioconda does not provide many of the core packages, e.g.
python, matplotlib no solution can be found.
Hello,
Is the information in Compiler tools / Aside CMake SysRoot still relevant for recent version of CMake/conda?
I see the CMake issue refered to is still open, but I can build a conda package with CMake without cross-linux.cmake toolchain file without issues (except for $AR not being properly detected). Will it break once in someonelse's computer?
Sorry if this can be answered with the current doc. I'm quite new to CMake and conda-build, and this is a lot of information at once.
We made the switch today from the old repo.continuum as it was giving us 404s to https://repo.anaconda.com/pkgs
there is some strange intermittent issue yielding this:
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to repo.anaconda.com:443
it happens maybe 20% of the time when cURLing to test
downloading a package
the network admins are suspicious it is something to do with cloudflare
we are sending our CLIENT_HELLO - OUT but do not get a SERVER_HELLO back IN
just wondering, i made my own channel on anaconda.org, but it doesn't have SHA256 data in the repodata? https://conda.anaconda.org/robostack/linux-64/repodata.json
is that expected or am I doing something wrong?
Hey all, I'm trying to configure a multi-user conda environment. I have a docker container that installs conda as the root user for a Jupyter notebook. At runtime, new Linux users are dynamically added. I want those users to be able to add packages to the environment, but they don't have write permissions. I've been trying to take a group-based approach, but if I
chown at the end of the Dockerfile, it adds approximately ten minutes to my build time. I'd like to preconfigure the ownership so that I can add/remove packages in the Dockerfile without having to chown at the end of the process. Is there an idiomatic way to handle this kind of problem? I've been referencing https://medium.com/@pjptech/installing-anaconda-for-multiple-users-650b2a6666c6 so far.
there is something about users in the conda-forge docker files: https://github.com/conda-forge/docker-images/blob/e7eacf673365e35809b4054e3d5f73d31bf6c246/scripts/entrypoint
not sure if this can help you
hi everyone ! I just clone the conda repo on my macOS 10.11 system and did source dev/start. I get conflicts:
Solving environment: ...working...
Found conflicts! Looking for incompatible packages.
This can take several minutes. Press CTRL-C to abort.
failed
UnsatisfiableError: The following specifications were found to be incompatible with a past
explicit spec that is not an explicit spec in this operation (conda):
- conda-build -> conda[version='>=4.1,<4.3|>=4.1|>=4.1,<4.4|>=4.3|>=4.5']
The following specifications were found to be incompatible with each other:
# and then pages after pages of conflicts...I'm not sure what to do about that..
it appears my ~/.condarc file, with the following content, created that situation:
auto_activate_base: false
changeps1: false
channels:
- conda-forge
- defaults
channel_priority: strict
anaconda_upload: falsethe super long list of conflicts ended with "Note that strict channel priority may have removed packages required for satisfiability.", which made me think of trying again after moving my ~/.condarc out of the way...
I think this is caused because the conda bin command is not actually on the path. I am on Windows 10, with the user-only install of Miniconda.
Should I file an issue or is there a simple way to correct this?
and with them, it depends on your Python version what files get installed
e.g. `pycache/....py38.pyc or something like that
Post install the list of installed files is pkg_name.json file in the conda-meta folder of the environment in the "files" key. That will include .pyc files generated for
noarch: python packages. Other packages, include noarch: generic will match the file list given in info/files or info/paths.json.
Conda will display the actions that is performs in the log if you run the command with
-vvv. Look for lines like:
TRACE conda.core.path_actions:execute(374): linking /home/jhelmus/conda/pkgs/imagesize-1.2.0-py_0/site-packages/imagesize-1.2.0.dist-info/RECORD => /home/jhelmus/conda/envs/test/lib/python3.8/site-packages/imagesize-1.2.0.dist-info/RECORDnoarch: generic has no special cases around files. The files in the package and linked/copied into the environment in the same manner as noarch: false packages. What makes them "special" is that they are not restricted to a particular platform.
For example
cph t ca-certificates-2019.5.15-1.tar.bz2 .conda