-
Notifications
You must be signed in to change notification settings - Fork 237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding CIBW_FROM_PYPI option #94
Conversation
I'm not 100% sure about adding this option, since we've discussed previously the possibility of moving off the Once we have this feature that transition is going to be quite a bit harder :/ Added to that, I'm not sure I totally understand the workflow when running in Travis CI or Appveyor - since those tools are designed to run as a result of a git change, not manually or reacting to a change in PyPI 🤔 Right now, (unless someone can change my mind 😄) I'd suggest writing a script to download the tarball from pypi, expand, and then invoke cibuildwheel on the resulting project directory. (so mark this a wontfix) |
@astrofrog Up to you to argue, here. I don't really mind either way. I just saw an easy way of implementing the requested feature in this PR. |
Note that as far as I can tell, using In particular the sentence in one of the replies Also, running setup.py directly will (after a long period of deprecation) be transitioned to implementation-defined behavior So I'm not sure it makes sense to transition to
I do something similar for conda packages - basically I have Travis and AppVeyor running as cron jobs, so that they can watch for changes in e.g. PyPI rather than react to changes in the git repo. In any case, I'm fine with just doing the downloading from PyPI myself - this was just an idea in case it was useful for others too :) |
4b06038
to
506d3ee
Compare
Cool, thanks for the info! I didn't know that pip will eventually inherit those commands. How do you run Travis/Appveyor as cron jobs? Just push empty commits to them every day or something? If we were to add something like this to cibuildwheel (which could be useful), I'd like it to be implemented separately from the (By the way, do we even need |
@joerick - Travis and AppVeyor both have options in the settings for setting up cron jobs, e.g. https://docs.travis-ci.com/user/cron-jobs/ I'll have a think about how |
Oh, interesting! I'm starting to get it :)
…Sent from my phone
On 16 Sep 2018, at 22:02, Thomas Robitaille ***@***.***> wrote:
@joerick - Travis and AppVeyor both have options in the settings for setting up cron jobs, e.g. https://docs.travis-ci.com/user/cron-jobs/
I'll have a think about how cibuildwheel --from-pypi my-project could be implemented.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
So, should we close this particular PR, then? |
Yes, I think so. I agree on the potential usefulness, just not this implementation. If you're happy to, lets close the PR, but keep the issue to track the feature request. |
Nope, no problem. Just saw the issue, thought of this approach, and wanted to test/propose it :-) |
First step towards addressing #93.
A nice extra is that I expect this will also work for a value
my-pypi-package==0.42.1
, building (or downloading, if the wheel already exists) that specific release.Things to do, if this approach works:
--from-pypi=...
argument?README.md
(depending on the actual form the option will take).collections.namedtuple
(e.g.,BuildOptions
) to nicely wrap all the options and only pass one argument tolinux.build
/macos.build
/windows.build
?EDIT: Sorry about initially pushing the commit to the master. Something went wrong, there.