Some weeks ago I created a conda environment for some old purposes. Now I need again the same environment but I do not remember the name I have used.
Question: Is there a way of asking the system "which environment do you have available"?
I am sure that I can found the one I am looking for because I normally use meaningful names. I have also used
history | grep conda
but there are no results. I suppose because XUbuntu deletes, periodically, the history of the terminal, right?
To list all environments
conda info --envs
Also, I found:
conda env list
It works properly as an alternative to the already proposed:
conda info --envs
Related
Lately, the mechanism used by Spack to manage the modules (I refer to the Environment Modules and to LMod) changed a little bit to allow a better integration with the spack environments (see pull request #23703).
Unfortunately, this also affect the fact that Spack does not update anymore the MODULE_PATH variable by default; indeed, the documentation still reports that
If you have installed a supported module system you should be able to run either module avail or use -l spack to see what module files have been installed.
but, at least on my machine, after installing a few packages, the module avail command does not show any new module (I am using commit 9936182). I suppose that this happens because now Spack want to know which environment should be loaded.
Of course,the problem could be easily fixed by adding the directory with the modules in the MODULE_PATH env var, but I am not sure that this is the best practice.
Is there a way to say to spack: "please, load the modules of the default environment?"
Thank you
pandoc-crossref must match the pandoc version, and also only the 3.10.0 release works on OSX Big Sur. Thus, it is not possible to get pandoc and pandoc-crossref running in a conda environment from the official channel or from conda-forge.
I could easily download the matching binaries from https://github.com/lierdakil/pandoc-crossref/releases/tag/v0.3.10.0 and copy them e.g. to the binpath:
$ which pandoc-crossref
/usr/local/bin/pandoc-crossref
$ curl -OL https://github.com/lierdakil/pandoc-crossref/releases/download/v0.3.10.0/pandoc-crossref-macOS.tar.xz
$ tar -xzvf pandoc-crossref-macOS.tar.xz
$ mv pandoc-crossref /usr/local/bin/pandoc-crossref
But I think that is not a clean approach, because conda will not know that I updated the version for pandoc-crossref.
What is a clean approach for updating a package managed by conda from a binary available on Github?
Update Feedstock
I updated it on the Conda Forge feedstock, which is what I regard as the "cleanest" solution.
How does one do that? First, OP had posted a comment on the feedstock in the PR that they wanted merged. This was the appropriate first step and hopefully in future cases that should be sufficient to prompt maintainers to act. In this case, it was not sufficient. So, as a follow up, I chatted on the Conda Forge Gitter to point out that the feedstock had gone stale and had non-responding maintainer(s). One of the core Conda Forge members suggested I make a PR bumping the version and adding myself as maintainer, and they merged it for me. In all, this took about 10 mins of work and ~2 hours from start to having an updated package on Anaconda Cloud.
Custom Conda Build
Otherwise, there isn't really a clean solution for non-Python packages outside of building a Conda package. That is, clone the feedstock or write a new recipe, modify it to build from the GitHub reference, then install that build into your environment. It may also be worth uploading to an Anaconda Cloud user account, so there is some non-local reference for it.
Pip Install (Python Packages Only)
In the special case that it is a Python package, one could dump the environment to YAML, edit to install the package through pip, then recreate the environment.
This is more of a general question about workflow than perhaps a detailed bug report. This has happened to me three times: I download Anaconda, work with it beautifully, perhaps installing one or two additional packages, but mostly working with Jupyter and Scipy/Numpy/Matplotlib. Then one day conda updates itself to next release (4.0 -> 4.1, or 4.0 ->4.2 depending on the machine) and all goes suddenly wrong. Should I refrain from using conda update and reinstall Anaconda from scratch? Is this a known issue? Is there another procedure or routine I should use, such as updating every few weeks?
It may be that certain other packages(dependencies) need to be updated as well.
conda update conda
conda update anaconda
You can also prevent conda from automatically updating by adding the following to your .condarc file(should be where you installed Anaconda or your user directory and it may be hidden)
auto_update_conda: False
I have a fresh Julia instalation on a machine that I want to use as a number-crunching server for various persons on a lab. There seems to be this nice package called jupyterhub wich makes the Jupyter Notebook interface avaible to various clients simultaneusly. A web page which I am unable to find again began suggesting something like "first install IJulia globally, then install JupyterHub..."
I cannot seem to find a nice way to install ONE package globally.
Update
In Julia-v0.7+, we need to use JULIA_DEPOT_PATH instead of JULIA_PKGDIR and the LOAD_PATH looks something like this:
julia> LOAD_PATH
3-element Array{Any,1}:
Base.CurrentEnv()
Any[Base.NamedEnv("v0.7.0"), Base.NamedEnv("v0.7"), Base.NamedEnv("v0"), Base.NamedEnv("default"), Base.NamedEnv("v0.7", create=true)]
"/Users/gnimuc/Codes/julia/usr/share/julia/stdlib/v0.7"
Old Post
"first install IJulia globally, then install JupyterHub..."
I don't know whether this is true or not, by following these steps below, you can install IJulia after you installed Jupyterhub.
Install packages system-wide/globally for every user
this question has already been answered here by Stefan Karpinski. so what we need is just use this method to install the IJulia.jl package.
There's a Julia variable called LOAD_PATH that is arranged to point at two system directories under your julia installation. E.g.:
julia> LOAD_PATH
2-element Array{Union(ASCIIString,UTF8String),1}:
"/opt/julia-0.3.3/usr/local/share/julia/site/v0.3"
"/opt/julia-0.3.3/usr/share/julia/site/v0.3"
If you install packages under either of those directories, then everyone using that Julia will see them. One way to do this is to run julia as a user who can write to those directories after doing export JULIA_PKGDIR=/opt/julia-0.3.3/usr/share/julia/site in the shell. That way Julia will use that as it's package directory and normal package commands will allow you to install packages for everyone....
Make IJulia working with Jupyterhub
in order to make IJulia and Jupyterhub working with each other for all the users, you should copy the folder your/user/.local/share/jupyter/kernels/julia/ to /usr/local/share/jupyter/kernels/. I write down some of the steps that I used in my test Dockerfile. the code is ugly, but it works.
Steps: (after you successfully installed Jupyterhub)
note that, you should do the following steps as root and I assume that your julia was globally installed at /opt/julia_0.4.0/.
make our global package directory and set up JULIA_PKGDIR:
mkdir /opt/global-packages
echo 'push!(LOAD_PATH, "/opt/global-packages/.julia/v0.4/")' >> /opt/julia_0.4.0/etc/julia/juliarc.jl
export JULIA_PKGDIR=/opt/global-packages/.julia/
install "IJulia" using package manager:
julia -e 'Pkg.init()'
julia -e 'Pkg.add("IJulia")'
copy kernelspecs to /usr/local/share/jupyter/kernels/ which can be used by any new user added by Jupyterhub:
jupyter kernelspec list
cd /usr/local/share/ && mkdir -p jupyter/kernels/
cp -r /home/your-user-name/.local/share/jupyter/kernels/julia-0.4-your-julia-version /usr/local/share/jupyter/kernels/
I'm brand new to python, using terminal, pip and virtual env.
From what I gather, the command 'source' activates the virtual environment and anything you do after that stays in the virtual environment like installing something with pip installs it only in your virtual environment. However, do I need to actually create a folder or choose a location first before I run source? In other words, does source create the virtual environment or only activate one that already exists?
This stuff is really hard to wrap my head around. I think one of the things that is hindering my development is that I'm not familiar with certain directory structures like bin, ect.
Once you create a virtualenv, you will see source created in the directory.
You must cd to that particular source and do source activate to start working on that particular virtualenv. Each virtualenv has its own source.
You can also use virtualenv wrapper to make things easier.
Look, you need to create the virtual enviroment first, with something like this:
virtualenv venv
Where 'venv' is the destination directory. After that you can run:
source venv/bin/activate
You can take a look at virtualenv help with:
virtualenv --help