Add rust unstable with the dev label #31
Comments
rth
changed the title
|
What if a new feedstock for |
What would be the advantage of that compared e.g. to having a separate brach in this repo? I know that some repos (e.g. https://github.com/conda-forge/qt-feedstock) have two parallel branches, but I'm not sure if anything specific needs to be done to publish the built packages from the non master branch to the server as well.
Right, but if it has a separate label, it will only be installed when the user explicitly provides and a different version scheme could be done there I imagine without impacting the rust package on the main conda-forge channel (unless I'm missing something)? |
|
Publishing under a different label using a different branch is how we prefer to handle RCs and such. |
|
How often would you want to update the unstable feedstock? Each set of Rust artifacts is about 750 MB, so daily updates might start getting to be a bit much even in these glorious days of The Cloud. |
|
Definitely not daily. Even a couple of times a year might do I think. For instance pyo3 can be run with rust unstable 1.30 even if the latest stable version is 1.31. So it's not about getting the latest nightly, but rather having a compiler which has the unstable features even if it's from some time ago. |
|
OK, cool. In that case I think this is definitely a good idea. If you want a reference for how to start packaging a new label, here's the patch I used for cairo not so long ago. If the autotick bot starts submitting PR's for the dev branch every day, we'll need some way to get it to chill out, but we can cross that bridge if/when we get there. |
|
Thanks. The other solution is to wait for PyO3 to get rid of specialization feature which seems to be on the roadmap for the next release. That would allow building Python extensions with rust stable, and will make this issue no longer necessary as far as I am concerned.. |
|
@pkgw Should we have a specialized rust-nightly package for things that need rust nightly instead? |
|
@mariusvniekerk Hmm, I think that might be the best approach. Could we implement a |
Add a feedstock recipe for building a 'rust-nightly' package from the upstream binary distribution tarballs. This recipe is based on: https://github.com/conda-forge/rust-feedstock And note some discussion there about building nightlies: conda-forge/rust-feedstock#31 One complication with the nightlies is that the source URLs for rust nightly builds are only versioned with the word 'nightly'. They don't contain an indication of the actual rust version that's included, and presumably they'll change from time to time. That leads to 2 issues: 1) The SHA hashes in the recipe may often be invalidated. "Fix" this by removing the hashes from meta.yaml. 2) The 'rust-nightly' package version is hard-coded in meta.yaml and so may fall out of sync with the internal rust version in the download. In this case the build would succeed, but the package version would be misleading. Fix this by including a build test to confirm that the rust version in the built package actually matches the package version. That will at least force a build break, rather than allowing creation of a mis-versioned package.
Add a feedstock recipe for building a 'rust-nightly' package from the upstream binary distribution tarballs. This recipe is based on: https://github.com/conda-forge/rust-feedstock And note some discussion there about building nightlies: conda-forge/rust-feedstock#31 One complication with the nightlies is that the source URLs for rust nightly builds are only versioned with the word 'nightly'. They don't contain an indication of the actual rust version that's included, and presumably they'll change from time to time. That leads to 2 issues: 1) The SHA hashes in the recipe may often be invalidated. "Fix" this by removing the hashes from meta.yaml. 2) The 'rust-nightly' package version is hard-coded in meta.yaml and so may fall out of sync with the internal rust version in the download. In this case the build would succeed, but the package version would be misleading. Fix this by including a build test to confirm that the rust version in the built package actually matches the package version. That will at least force a build break, rather than allowing creation of a mis-versioned package.
|
Fixed in #52, merged to the new |
While the ability to install rust with conda is quite nice, something I have found limiting so far is the ability to install rust unstable needed for some packages/crates.
As far as I understood, features currently in rust unstable have no guarantee of making into the stable, and so when those are needed by a crate, waiting for the next release of rust is not a viable solution.
In particular, rust unstable is currently required by https://github.com/PyO3/pyo3 (bindings for CPython C API) and as a result https://github.com/rust-numpy/rust-numpy (binding for numpy C API). Given the amount of Python package on conda-forge, I think it is quite important to be able to build a Python package with a "C" extension written in Rust.
If you think it's a good idea, I can (try) to make a PR to add rust unstable under e.g.
devlabel (or some other non-default label).The text was updated successfully, but these errors were encountered: