We would like to position Conda as a language-agnostic package manager, but at present it maintains a distinct bias towards Python. Given its origins this was expected and, frankly, reasonable. Nevertheless, as we begin to use it to subsume other packaging ecosystems, such as CRAN, NPM, Ruby Gems, etc., we are going to want to overcome this history; and one key challenge is to address naming conflicts across platforms.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
#!/usr/bin/env bash | |
set -eux | |
OS="$(gawk -F= '/^NAME/{print $2}' /etc/os-release | sed 's/"//g')" | |
echo "Detected ${OS} Distro" | |
if [[ "$OS" =~ ^(CentOS\ Linux|RedHat|Ubuntu)$ ]]; then |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
machine: | |
environment: | |
MINICONDA: "$HOME/miniconda" | |
MINICONDA_PATH: "$MINICONDA/bin" | |
PATH: "$MINICONDA_PATH:$PATH" | |
CONDA: "$MINICONDA_PATH/conda" | |
ANACONDA: "$MINICONDA_PATH/anaconda" | |
# This ensures we don't accidentally pull in ~/.condarc | |
# if it happens to be there for some strange reason | |
CONDARC: "$MINICONDA/condarc.none" |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# usage: python rearch.py <spec-that-resolves-to-noarch-package> | |
# 1. creates a directory derived from the spec (replacing ':/=' with dashes) | |
# 2. creates a conda recipe to build a python-version-specific package | |
# 3. runs the conda recipe for PYTHON_VERSIONS | |
# 4. runs conda-convert to obtain the other platforms | |
# leaves everything in the given directory. | |
import os | |
import shutil | |
import sys |
There are many situations where we are inclined to produce multiple variants of the same package, with each variant depending on a different set of low-level dependencies. For instance:
- A numerical package might rely on the use of the Basic Linear Algebra Subprograms (BLAS).
In this note, I propose a modification to conda
and to its implied package specification that will provide, in my view, a solution to a common pitall of the conda
ecosystem, and will provide additional performance benefits as well.
With conda
, as with many package ecosystems, it is often necessary for a package to place version constraints on its dependencies to ensure that they interoperate properly. In practice, such constraints must balance two competing concerns:
- if the constraints are specified too tightly, then packages will often unable to coexist, because their version constraints will conflict. For example, if package
A
depends onB <2.0
, and packageC
depends onB >2.0
, then packagesA
,B
, andC
cannot coexist. The tighter the constraints, the more likely this is to happen. - on the other hand, if the constraints are specifed too loosely, then packages will often break if one of their dependencies ce
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
NewerOlder