Skip to content

Move to Conda-Forge? #2

@rlizzo

Description

@rlizzo

@lantiga

Now that we have the recipes stable and building (on linux64 atleast), I'm thinking of the best way to build the packages in the long term. I've been looking into conda-forge, and think that it may be a solution we may want to adopt in the long term. There are a number of benefits to this approach:

  1. Automatic compilation, building, and distribution on linux, mac, and windows systems.
  2. Building binaries which are compatible with other systems and with packages from the default channel (VTK is a notable concern in this regard).
  3. Inclusion in a channel with a great deal of respect/influence in the anaconda influence (and a large user-base to boot).

You can read more about the benefits of conda-forge here.

In order to make the move the process is fairly simple, the steps are outlined below:

  1. Fork the conda-forge/staged-recipes repository.
  2. Make a new folder in recipes for your package. Look at the example recipe and our FAQ for help.
  3. Open a pull request. Building of your package will be tested on Windows, Mac and Linux.
  4. When your pull request is merged a new repository, called a feedstock, will be created in the github conda-forge organization, and build/upload of your package will automatically be triggered. Once complete, the package is available on conda-forge.

Let me know your thoughts and I'll start working on building an appropriate meta.yaml and build.sh / build.bat file for the conda-forge tool. If this is a route we want to go down it may be best to do it from day 1 so that when VMTK users start using the anaconda packaging, they have the conda-forge channel as their default and will recieve updates with no intervention in the future.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions