Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

More input/output options from the condaverse (and beyond)

See original GitHub issue

Proposed change

What would the interest level be in some PRs for:

input files
- conda environment.yaml
  - this is supported, while not as widely used
  - probably a one-liner
- conda requirements.txt
  - conda also supports this file, but is generally inferior to environment.yml… so i wouldn’t propose supporting it. EXCEPT for a huge reproducibility/performance corner case. conda list --explicit will include the canary line @EXPLICIT and list the exact URLs (but no hashes 😭) of the packages to be installed. An environment created from this file won’t even invoke the solver, so you don’t pay that tax at all. It cannot, however, include pip packages.
- anaconda-project.yml and anaconda-project-lock.yml (and .yaml variants)
  - basically it’s a meta-environment.yml that can create multiple environments, support environment inheritance, environment variables (sadly, only globally) and run comands in particular environments
  - when coupled with an anaconda-proejct-lock.yml it achieves about the best level of reproducibility I’ve been able to get, and lets you do things like maintain an env on linux-64, but also perform the last-known-good solution for win-64 and osx-64 with one command.
  - i’ve had a stormy relationship with this tool, but it’s still kind of the best thing out there in conda-land
output formats
- constructor installers
  - i’ve been hacking together something that works basically like repo2docker but uses platform-specific, offline-capable installers as the delivery mechanism
    - gets around the noarch: python thing by stuffing all those packages into a channel-in-a-package and installing them at post-install… could be expanded to support wheels, yarn (the JS one) offline mirrors, or whatever else doesn’t need the internet or a reasonable facsimile thereof to do its installation thing
- conda-pack archives
  - kind of the same idea as constructor, but you get a relocatable, platform-specific environment tarball out at the end
- packer ???
  - packer is super boss go executalbe that can make almost anything (OVA, ISO, docker, AMI, VMware, etc)

Alternative options

don’t do them
make some entry_points or namespace packages so they could be done, but not do them in this repo
prototype fork

Who would use this feature?

Dunno, conda people. People that don’t run docker. People that want stuff that installs at the end of the day, given bzip, rather than just runs and goes poof. People on windows. Peopl on ARM. People at conferences that want to install large, usable software environments.

How much effort will adding it take?

Varies based on which ones we’re interested in.

Who can do this work?

I would be capable of doing all the work above, and it would trickle in really slowly, or potentially my $DAY_JOB alter ego might chip in if i can make the right case. Of the repo maintainers, I would just be asking for bounding of stuff that would be way out of scope, and review as the technical challenges are overcome.