conda-forge / conda-forge-anvil

conda-forge conda-constructor

anvil

conda-forge conda-constructor

• currently Linux and macOS only
• currently Python 2.7, 3.4, and 3.5 only
• currently testing both OS on Travis as to whether constructors can be downloaded from this repo and run

conda-forge-anvil's Issues

Name?

Was called anvil previously. Maybe that should stay? Have prefixed it with conda-forge- so it is easier to find. Though am open to suggestions. Please share your thoughts.

Break out Linux builds to CircleCI

Given we use CircleCI for everything else when we build on Linux, it seems reasonable that we do this here too. This also makes sense in light of some issues we have had with Travis CI. So this should help make sure we are not too reliant on it as a service.

Packages included

Something worth discussing is what packages we should include. It probably goes without saying that we want the standard packages found in a Miniconda install. Though there has been discussion about this replacing the need for caching at staged-recipes ( conda-forge/staged-recipes#610 (comment) ) and feedstocks ( conda-forge/conda-smithy#176 (comment) ). As a result, we will need more things like conda-build-all for staged-recipes or conda-forge-build-setup used for CI configuration. Some of these may not make sense or be needed by the average user. So it is probably worth discussing whether they should be included the base installer and if not how we want to tier our installers (e.g. mini-anvil vs. ci-anvil).

pycrypto is unmaintained and vulnerable

Why is pycrypto used over pycryptodome?

conda-forge-anvil/recipes/construct.yaml

Line 40 in 56db5fe

- pycrypto

This project is no longer maintained: pycrypto/pycrypto#285

Versioning

Another topic for discussion is how do we do versioning of the installer? Related to it, do we pin versions of packages within the installer?

Included channels

An important question we should discuss is what channels to include. Currently we include the conda-forge channel and the free channel from defaults. conda itself appears to include a few channels that it calls defaults, which include the free channel, the pro channel, and msys2 channel (on Windows).

Should we include all of these channels? Should we just include the conda-forge channel and allow users/ourselves to add the other ones later?

Making releases

Currently it seems we are including releases in the repo. It is probably worth discussing whether we want to continue that trend. The main concern is these are heavy binary objects living in the git history, which is something git does not normally deal with well.

Another way we might do this is using GitHub tags instead. The benefit of the latter approach is we can see what commits generate a release. Though we still can download the latest published release if we want.

When making releases, it would be good if we published checksums with that release. That way people can ensure that the installer they downloaded matches that release.

Perhaps there are other methods of doing releases that are worth discussing.

Build on AppVeyor

We should get a working build on AppVeyor as well.