I'm trying to search for a package, specifying the Python version. I have tried:
# Find Python 2.7 packages for 'numpy'
conda search "numpy=py27_0" --info
No match found for: numpy=py27_0. Search: *numpy*=py27_0
conda search "numpy==py27_0" --info
No match found for: numpy==py27_0. Search: *numpy*==py27_0
How can I specify the Python version, e.g. 2.7, 3.6?
There isn't a direct mechanism to constrain Python version outside of running the actual solver. However, the major channels use the Python version (say 3.8) to generate a string (say "py38") that is included in the build string. This can thus be used as proxy, by searching for constraints on the build string. For example, the following (equivalent) expressions should pick up all Python 2.7 builds of numpy in the configured channels:
## search all versions with 'py27' build string
conda search 'numpy=*=*py27*'
## alternative (MatchSpec) syntax
conda search 'numpy[build=*py27*]'
The first version must explicitly specify the version as unconstrained ("*"); the latter directly specifies the build constraint, with the unconstrained version implied.
Related
If I run conda info sphinx from the command line, the last entry as of August 24, 2017, is
sphinx 1.6.3 py36_0
-------------------
file name : sphinx-1.6.3-py36_0.tar.bz2
name : sphinx
version : 1.6.3
build string: py36_0
...
What is the meaning of the build string, which is mirrored above in the package version? Is this the minimum version of the python interpereter required by a package?
The first part of the build string (pyXX) of this package tells you the exact version of the Python interpreter that this package can be used for. Most likely, there are other packages for other versions of Python (py27, py35, etc.). The second part (after the underscore) tells you the build number of this package. The build number is typically incremented when there is a change in the build recipe, but no change in the version of the software being built. You can find more information in the description of the info/index.json fields.
Note, however, that the build string will be changing with conda build 3.0.
Package maintainers can customize their build strings using meta.yml (see Conda Build Documentation on Build section).
I am generating conda dependencies YAML and I don't entirely understand the information that is presented there. In pandas=1.2.4=py38h1abd341_0 I know that it is pandas 1.2.4 version but what is py38h1abd341_0?
That is the build string, documented here. The py38 indicates the package is built for Python 3.8. The 8 characters after that are a hexidecimal hash of the package dependencies, to differentiate variants that can be used to satisfy different dependencies (think glibc on Linux or the MSVCRT on Windows).
After the underscore is the build number, which is incremented when the package recipe changes but the package version does not change.
The new hash was introduced with Conda Build 3
I'd like to distribute multiple versions of a package through conda. Specifically, I'd like to do something like this:
...
package-v1.2-dev
package-v1.2
package-v1.1-dev
package-v1.1
package-v1.0
The trick is that I'd like to have the "latest" or default package be the release versions that do not have -dev. As I understand it, conda install <package> without a version number will install the newest build. In my case, that will always be -dev. Is it possible to make the default a specific version number?
You can achieve this by specifying a custom "label" for your dev packages. Keep using the default main label for your release packages, but use a non-main label (e.g. dev) for the other packages.
First, a quick note about version numbers: conda package versions must not contain the - character, so v1.2-dev is not a valid version. For the following examples, I'll use v1.2.dev.
Here's how to upload your packages:
anaconda upload mypackage-v1.2.tar.bz2
anaconda upload --label dev mypackage-v1.2.dev.tar.bz2
(You can also manipulate the labels for existing packages via your account on the http://anaconda.org website.)
By default, your users will only download your main packages. Users who want the dev packages will have two choices:
They can specify the dev label on the command-line:
conda install -c mychannel/label/dev mypackage
OR
They can add your dev label to their .condarc config
# .condarc
channels:
- mychannel/label/dev # dev label
- mychannel # main label only
- conda-forge
- defaults
And then there's no need to specify the channel on the command-line:
conda install mypackage
PS -- Here's a side note about something you wrote above:
As I understand it, conda install <package> without a version number will install the newest build
Just to clarify, it doesn't install the "newest" in chronological sense, but rather the highest compatible version according to conda's VersionOrder logic. That logic is designed to be largely compatible with relevant Python conventions (e.g. PEP440 and others), but with some affordances for compatibility with other languages' conventions, too.
Please note: As far as conda (and PEP440) is concerned, 1.2.dev comes BEFORE 1.2. (Maybe you already knew that, but I don't consider it obvious.)
$ python
>>> from conda.models.version import VersionOrder
>>> VersionOrder('1.2.dev') < VersionOrder('1.2')
True
We use YAML files to specify our conda and pip environments. In them we can specify which version numbers we need using, for example, any one of these lines
- cudatoolkit=10.2.89
- cudatoolkit=10.2.*
- cudatoolkit==10.2.89
- cudatoolkit==10.2.*
I am having trouble finding the documentation for what == vs. = means in these package requirements and what other restrictions could be written and how.
What is the difference in this setting between = and ==? Do these meanings differ between conda and pip? Where is the correct documentation (Google & Bing are not great at searching for symbols like those)?
In PEP 440, pip's version specification operators include only == which means to match the exact version specified. Conda's package matching specifications include == which is the same as PEP 440's == for exact version specification and their own operator, =, which is for fuzzy package matching.
I used pip to get .whl file for numpy
pip wheel --wheel-dir=./ numpy
and I have got numpy-1.13.3-cp27-cp27mu-linux_armv7l.whl because I am using ARM platform, but when run pip for protobuf
pip wheel --wheel-dir=./ protobuf
I got protobuf-3.4.0-py2.py3-none-any.whl
So, why isn't linux_armv7l like the case of numpy, I didn't alter the machine and searched for that difference but no information.
thanks for advice .
Let's split package names by components:
numpy — package name
1.13.3 — package version
cp27 — the package was compiled to be used with this version of Python
cp27mu — compilation flags
linux — operating system
armv7l — processor architecture
This means that package numpy contains binary extensions written in C and compiled for specific processor, OS and Python version.
The following package is pure Python:
protobuf — name
3.4.0 — version
py2.py3 — the package is written in highly portable manner and is suitable for both major versions of Python
none — is not OS-specific
any — suitable to run on any processor architecture
The wheel filename is {distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl.
distribution
Distribution name, e.g. 'django', 'pyramid'.
version
Distribution version, e.g. 1.0.
build tag
Optional build number. Must start with a digit. A tie breaker if two wheels have the same version. Sort as the empty string if unspecified, else sort the
initial digits as a number, and the remainder lexicographically.
language implementation and version tag
E.g. 'py27', 'py2', 'py3'.
abi tag
E.g. 'cp33m', 'abi3', 'none'.
platform tag
E.g. 'linux_x86_64', 'any'.
reference is here.