conda-forge/conda-smithy
| Src: https://github.com/conda-forge/conda-smithy
| Homepage: https://conda-forge.github.io/ :
"conda-forge https://github.com/conda-forge is a github organization
containing repositories of conda recipes. Thanks to some awesome continuous
integration providers (AppVeyor, CircleCI and TravisCI), each repository,
also known as a feedstock, automatically builds its own recipe in a clean
and repeatable way on Windows, Linux and OSX"
https://conda-forge.github.io/feedstocks.html
so, for psutil-feedstock:
https://github.com/conda-forge/psutil-feedstock
-
https://github.com/conda-forge/psutil-feedstock/blob/master/recipe/meta.yaml
- https://github.com/conda-forge/psutil-feedstock/blob/master/appveyor.yml
-
https://github.com/conda-forge/psutil-feedstock/blob/master/ci_support/run_d...
- https://github.com/conda-forge/psutil-feedstock/blob/master/.travis.yml
…
https://github.com/conda-forge/conda-smithy/tree/master/conda_smithy/templat...
On Thursday, May 26, 2016, Robert T. McGibbon
I want to get something setup that would allow people to only need to upload a source release to PyPI and then have wheels automatically built for them (but not mandate that- Projects that wish it should always be able to control their wheel generation). I don’t know what that would specifically look like, if someone is motivated to work on it I’m happy to help figure out what it should look like and provide guidance where I can, otherwise it’ll wait until I get around to it.
One first step towards this that's a natural follow-on to the manylinux work might be to define a overall build configuration file / format and process for automating the whole wheel build cycle (i'm thinking of something modeled after conda-build) that would, among other things
for potentially multiple versions of python: - run `pip wheel` (or setu.py bdist_wheel) to compile the wheel - run `auditwheel` (linux) or `delocate` (osx) to bundle any external libraries
-Robert
On Thu, May 26, 2016 at 2:47 PM, Donald Stufft
javascript:_e(%7B%7D,'cvml','donald@stufft.io');> wrote: On May 26, 2016, at 2:41 PM, Matthew Brett
javascript:_e(%7B%7D,'cvml','matthew.brett@gmail.com');> wrote: On Thu, May 26, 2016 at 2:28 PM, Daniel Holth
javascript:_e(%7B%7D,'cvml','dholth@gmail.com');> wrote: Maybe there could be a way to say "the most recent release that has a wheel for my platform". That would help with the problem of binaries not being available concurrently with a new source distribution.
Yes, that would certainly help get over some of the immediate problems.
Sorry for my ignorance - but does ``--only-binary`` search for an earlier release with a binary or just bomb out if the latest release does not have a binary? It would also be good to have a flag to say "if this is pure Python go ahead and use the source, otherwise error". Otherwise I guess we'd have to rely on everyone with a pure Python package generating wheels.
I believe it would find the latest version that has a wheel available, I could be misremembering though.
It would be very good to work out a plan for new Python releases as well. We really need to get wheels up to pypi a fair while before the release date, and it's easy to forget to do that, because, at the moment, we don't have much testing infrastructure to make sure that a range of wheel installs are working OK.
I want to get something setup that would allow people to only need to upload a source release to PyPI and then have wheels automatically built for them (but not mandate that- Projects that wish it should always be able to control their wheel generation). I don’t know what that would specifically look like, if someone is motivated to work on it I’m happy to help figure out what it should look like and provide guidance where I can, otherwise it’ll wait until I get around to it.
— Donald Stufft
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org javascript:_e(%7B%7D,'cvml','Distutils-SIG@python.org'); https://mail.python.org/mailman/listinfo/distutils-sig
-- -Robert