mcg1969

#!/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

mcg1969

mcg1969

# 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

mcg1969

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"

mcg1969

Conda proposal: virtual hotfixing via build groups

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.

Motivation

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 on B <2.0, and package C depends on B >2.0, then packages A, B, and C 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

mcg1969

mcg1969

mcg1969

mcg1969

mcg1969

Conda Proposal: namespaces

Motivation

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.