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_docker_build.sh - https://github.com/conda-forge/psutil-feedstock/blob/master/.travis.yml … https://github.com/conda-forge/conda-smithy/tree/master/conda_smithy/templates On Thursday, May 26, 2016, Robert T. McGibbon <rmcgi...@gmail.com> wrote: > > 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 <don...@stufft.io > <javascript:_e(%7B%7D,'cvml','don...@stufft.io');>> wrote: > >> >> > On May 26, 2016, at 2:41 PM, Matthew Brett <matthew.br...@gmail.com >> <javascript:_e(%7B%7D,'cvml','matthew.br...@gmail.com');>> wrote: >> > >> > On Thu, May 26, 2016 at 2:28 PM, Daniel Holth <dho...@gmail.com >> <javascript:_e(%7B%7D,'cvml','dho...@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 >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
