search

conda-forge / conda-forge.github.io

The conda-forge website.
https://conda-forge.org
BSD 3-Clause "New" or "Revised" License
132 stars 279 forks source link

versioning non-Python runtimes #244

Open minrk opened 8 years ago

minrk commented 8 years ago

I'm investigating upgrading nodejs (https://github.com/conda-forge/nodejs-feedstock/pull/6) to 6, but ran into the fact that downstream packages really need to be tied to at least the major, and probably minor, version of node, so issuing the upgrade would likely break all downstream packages. The same likely goes for any non-Python runtime, including R (most used on conda), ruby, etc.

So my questions are:

  1. what's in-scope for conda-forge (matrix builds of nodejs versions, ruby versions, etc. like CI services have?)
  2. what's in-scope for conda itself (a generic mechanism analogous to CONDA_PY?)
  3. how do we specify which nodejs version for a package (track features, or just pin the minor version in recipe.yml?)

I think the general question brought up elsewhere of pinning versions of dependencies at build-time would also ease this issue.

jakirkham commented 6 years ago

While we didn't have a great answer for this at the time for anything that wasn't Python, Perl, R, or Lua, think this would be solvable with conda-forge-pinning in the conda-build 3 era (using related tooling like a new conda-smithy). Would encourage you to submit a PR with versions of nodejs and/or other things over there and we can figure out a reasonable solution.

minrk commented 6 years ago

Good point. I think setting run_exports on runtime packages will go a long way.