This project is now somewhat deprecated, use conda-verify instead.
anaconda-verify is a tool for (passively) verifying conda recipes and conda packages.
$ conda install anaconda-verify $ anaconda-verify -h $ anaconda-verify <path to recipes or packages>
The purpose of this verification process is to ensure that recipes don't contain obvious bugs, and that the conda packages we distribute to millions of users meet our high quality standards.
Historically, the conda packages which represent the Anaconda distribution
were not created using
conda-build, but an internal build system.
conda-build started as a public fork of this internal system
3 years ago. At that point the Anaconda distribution had already been
around for almost a year, and the only way to create conda packages
was by using the internal system.
conda-build has made a lot of progress, the internal system basically
stayed unchanged, because the needs on a system for building a distribution
are quite different, and not driven by the community using
for continuous integration and other language support (e.g. Perl, Lua), etc. .
On the other hand, the internal system has been developed to support
Anaconda distribution specific needs, such as MKL featured packages,
source and license reference meta-data, and interoperability between
collections of packages.
In an effort to bridge the gap between our internal system and
we started using
conda-build to create conda packages for the Anaconda
distribution itself about one year ago.
By now, more than 85% of the conda packages in the Anaconda distribution
are created using
However, because the different requirements mentioned above, we only allow
certain features that
This also helps to keep
recipes simple and maintainable, and functional with the rest of the
internal system which reads meta-data from the recipes.
This is why we require conda recipes to be valid according to this tool.
Another aspect of
anaconda-verify is the ability to verify conda packages.
These are the most important checks
anaconda-verify performs on conda
packages, and more importantly we explain why these checks are necessary
Ensure the content of
info/filescorresponds to the actual archived files in the tarball (except the ones in
info/, obviously). This is important, because the files listed in
info/filesdetermine which files are linked into the conda environment. Any mismatch here would indicate either (i) the tarball contains files which are not getting linked anywhere or (ii) files which do no exist are attempted to get linked (which would result in an error).
Check for now allowed archives in the tarball. A conda package should not contain files in the following directories
envs/, because this would (for example) allow a conda package to modify another existing environment.
Make sure the
buildvalues exist in
info/index.jsonand that they correspond to the actual filename.
Ensure there are no files with both
.exeextension. For example, if you had
Scripts/foo.exeone would shadow the other, and this would become confusing which one is actually executed when the user types
foo. Although this check is always done, it is only relevant on Windows.
easy-install.pthfile exists. These files would cause problems as they would overlap (two or more conda packages would contain a
easy-install.pthfile, which overwrite each other when installing the package).
Ensure no "easy install scripts" exists. These are entry point scripts which setuptools creates which are extremely brittle, and should by replaced (overwritten) by the simple entry points scripts
Ensure there are no
.sofiles have a
.pyfile next to it. This is just confusing, as it is not obvious which one the Python interpreter will import. Under certain circumstances setuptools creates
.pynext to shared object files for obscure reasons.
For packages (other than
python), ensure that
.pycare not in Python's standard library directory. This would happen when a
.pycfile is missing from the standard library, and then created during the build process of another package.
Check for missing
.pycfiles cause two types of problems: (i) When building new packages, they might get included in the new package. For example, when building scipy and numpy is missing
.pycfiles, then these (numpy
.pycfiles) get included in the scipy package (ii) There was a (buggy) Python release which would crash when
.pycfiles could not written (due to file permissions).
Ensure Windows conda packages only contain object files which have the correct architecture. There was a bug in
conda-buildwhich would create
64-bitentry point executables when building
32-bitpackages on a
site-packagesdoes not contain certain directories when building packages. For example, when you build
pandasyou don't want a
setuptoolsdirectory to be contained in the
pandaspackage. This would happen when the
pandasbuild dependencies have missing
Here is an example of running the tool on conda packages:
$ anaconda-verify bitarray-0.8.1-py35_0.tar.bz2 ==> /Users/ilan/aroot/tars64/bitarray-0.8.1-py35_0.tar.bz2 <== bitarray
In this case all is fine, and we see that only the
bitarray directory is