Fwd: Putting `blist` into collections module
And forwarding to the list because Google Groups is still broken as a mailing list mirror. ---------- Forwarded message ---------- From: Nick Coghlan <ncoghlan@gmail.com> Date: 21 September 2014 22:26 Subject: Re: [Python-ideas] Putting `blist` into collections module To: Ram Rachum <ram.rachum@gmail.com> Cc: "python-ideas@googlegroups.com" <python-ideas@googlegroups.com> On 21 September 2014 01:18, Ram Rachum <ram.rachum@gmail.com> wrote:
I realize that way more than a few months have passed, but I'd still like to give my input. I really wish that `blist` would be made available in the `collections` module. I'm working on an open-source project right now that needs to use it and I'm really reluctant to include `blist` as a dependency, given that it would basically mean my package wouldn't be pip-installable on Windows machines.
I didn't originally notice that your main concern was with installation on Windows. For that particular concern, I suggest filing an RFE with the blist project, requesting that they publish wheel files for Windows. Offering to help in building them would likely be appreciated, as many projects may not have access to systems that allow them to build Windows binaries (alternatively, if Daniel approached the PSF for assistance in providing Windows binaries, we can generally provide some help in situations like that, especially to folks that have already been accepted as CPython core developers). "Compilation can be hard on Windows" is no longer a factor that is taken into account when deciding whether or not to add things to the standard library - we're taking other steps to deal with that problem as part of the packaging toolchain, and one of the key ones is allowing publication of binary wheels for Mac OS X and Windows on PyPI. (Further down the track, we'd like to offer a build farm as part of PyPI, but we're still a *long* way from reaching a point where such a proposal can be seriously considered) Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, 21 Sep 2014 22:36:35 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
"Compilation can be hard on Windows" is no longer a factor that is taken into account when deciding whether or not to add things to the standard library
Where is the pronouncement or discussion on that point?
- we're taking other steps to deal with that problem as part of the packaging toolchain, and one of the key ones is allowing publication of binary wheels for Mac OS X and Windows on PyPI.
I don't see how that changes anything. The hard (or, at least, tedious) part is not publishing packages, it's building the packages in the first place. "setup.py upload" has always worked fine. Regards Antoine.
On 21 September 2014 22:53, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 21 Sep 2014 22:36:35 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
"Compilation can be hard on Windows" is no longer a factor that is taken into account when deciding whether or not to add things to the standard library
Where is the pronouncement or discussion on that point?
"no longer taken into acount" was too strong - "has significantly less weight due to the existence of other options" is more accurate. It's still part of the rationale for the ssl feature backports, for example.
- we're taking other steps to deal with that problem as part of the packaging toolchain, and one of the key ones is allowing publication of binary wheels for Mac OS X and Windows on PyPI.
I don't see how that changes anything. The hard (or, at least, tedious) part is not publishing packages, it's building the packages in the first place. "setup.py upload" has always worked fine.
Yep, one of the later steps is a build farm integrated into PyPI, so you can just upload the tarball in most cases and you're done. We' re still a *long* way from having that be feasible at this point, but we'll get there eventually. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, Sep 21, 2014 at 8:20 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 21 September 2014 22:53, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 21 Sep 2014 22:36:35 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
"Compilation can be hard on Windows" is no longer a factor that is taken into account when deciding whether or not to add things to the standard library
Where is the pronouncement or discussion on that point?
"no longer taken into acount" was too strong - "has significantly less weight due to the existence of other options" is more accurate. It's still part of the rationale for the ssl feature backports, for example.
- we're taking other steps to deal with that problem as part of the packaging toolchain, and one of the key ones is allowing publication of binary wheels for Mac OS X and Windows on PyPI.
I don't see how that changes anything. The hard (or, at least, tedious) part is not publishing packages, it's building the packages in the first place. "setup.py upload" has always worked fine.
Yep, one of the later steps is a build farm integrated into PyPI, so you can just upload the tarball in most cases and you're done. We' re still a *long* way from having that be feasible at this point, but we'll get there eventually.
Cheers, Nick.
There's also an option that's free for Open Source that I've been looking at for some Ruby projects I maintain. AppVeyor [1] is a continuous integration system that integrates well with services like GitHub and BitBucket and will build wheels for Python projects once they've passed tests. This may be a good solution until PyPI can produce a build farm. A quick search of GitHub shows that this seems to be picking up momentum in the Python community more than others. [1]: http://www.appveyor.com/
On 21 September 2014 23:27, Ian Cordasco <graffatcolmingov@gmail.com> wrote:
There's also an option that's free for Open Source that I've been looking at for some Ruby projects I maintain. AppVeyor [1] is a continuous integration system that integrates well with services like GitHub and BitBucket and will build wheels for Python projects once they've passed tests. This may be a good solution until PyPI can produce a build farm.
Oh, that's very cool - yes, I'll definitely recommend it to folks now I'm aware of it :)
A quick search of GitHub shows that this seems to be picking up momentum in the Python community more than others.
If it means more wheel files on PyPI, even before we're able to put together a build farm, great :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 21 September 2014 14:47, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 21 September 2014 23:27, Ian Cordasco <graffatcolmingov@gmail.com> wrote:
There's also an option that's free for Open Source that I've been looking at for some Ruby projects I maintain. AppVeyor [1] is a continuous integration system that integrates well with services like GitHub and BitBucket and will build wheels for Python projects once they've passed tests. This may be a good solution until PyPI can produce a build farm.
Oh, that's very cool - yes, I'll definitely recommend it to folks now I'm aware of it :)
That's a *very* good point. I was aware of AppVeyor as a CI tool, I'd thought of it as essentially "Travis for Windows" but it had never occurred to me that it would work for building wheels as well. I may try to put together a "How to set up AppVeyor to build wheels for your project" document - Ian, do you have any examples of projects doing this, that I could look to for details? Paul
I'm guessing the appveyor.yml file might look like this: install: - cinst python - cinst pip - pip install wheel build: off # It's Python; no building allowed! test_script: - py.test # or whatever to run tests deploy_script: - python setup.py sdist bdist_wheel upload On Sun, Sep 21, 2014 at 3:54 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 21 September 2014 14:47, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 21 September 2014 23:27, Ian Cordasco <graffatcolmingov@gmail.com> wrote:
There's also an option that's free for Open Source that I've been looking at for some Ruby projects I maintain. AppVeyor [1] is a continuous integration system that integrates well with services like GitHub and BitBucket and will build wheels for Python projects once they've passed tests. This may be a good solution until PyPI can produce a build farm.
Oh, that's very cool - yes, I'll definitely recommend it to folks now I'm aware of it :)
That's a *very* good point. I was aware of AppVeyor as a CI tool, I'd thought of it as essentially "Travis for Windows" but it had never occurred to me that it would work for building wheels as well.
I may try to put together a "How to set up AppVeyor to build wheels for your project" document - Ian, do you have any examples of projects doing this, that I could look to for details? Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/
On 21 September 2014 22:47, Ryan Gonzalez <rymg19@gmail.com> wrote:
I'm guessing the appveyor.yml file might look like this:
install: - cinst python - cinst pip - pip install wheel
build: off # It's Python; no building allowed!
test_script: - py.test # or whatever to run tests
deploy_script: - python setup.py sdist bdist_wheel upload
The one I'm working from (cookiecutter) is more complex - essentially because it manually installs Python etc. I'd not seen cinst before, but from a quick search I see that's chocolatey. So yes, something like that. Can you specify which version of Python cinst installs? You'd actually want to make sure you had all the versions of Python you supported installed. Also, you probably couldn't do the upload in deploy_script unless you were willing to store your credentials in AppVeyor. But essentially, it's not hard to set up, AFAICT. Paul
On 21 September 2014 23:16, Paul Moore <p.f.moore@gmail.com> wrote:
On 21 September 2014 22:47, Ryan Gonzalez <rymg19@gmail.com> wrote:
I'm guessing the appveyor.yml file might look like this:
install: - cinst python - cinst pip - pip install wheel
build: off # It's Python; no building allowed!
test_script: - py.test # or whatever to run tests
deploy_script: - python setup.py sdist bdist_wheel upload
The one I'm working from (cookiecutter) is more complex - essentially because it manually installs Python etc. I'd not seen cinst before, but from a quick search I see that's chocolatey. So yes, something like that. Can you specify which version of Python cinst installs? You'd actually want to make sure you had all the versions of Python you supported installed.
Also, you probably couldn't do the upload in deploy_script unless you were willing to store your credentials in AppVeyor.
But essentially, it's not hard to set up, AFAICT. Paul
Also, I've yet to work out how to get AppVeyor to do 32-bit and 64-bit builds. But I'm looking into it... Paul
After more testing, my code doesn't work. AppVeyor seems to come with Python 3.4 and 2.7 installed in their usual locations on drive C. I'm testing it out at https://github.com/kirbyfan64/appveyor_python. My new file looks like this: install: - ps: (new-object net.webclient).DownloadFile(' https://raw.github.com/pypa/pip/master/contrib/get-pip.py', 'C:/get-pip.py') # install pip - C:/Python34/python.exe C:/get-pip.py # install pip part 2 - C:/Python34/Scripts/pip.exe install wheel # install wheel build_script: - python setup.py build # or whatever test_script: - py.test # or something else deploy_script: - python setup.py sdist bdist_wheel upload The build hasn't completed, though; I'm still waiting for the results. I keep making dumb mistakes with pytest. Status is at https://ci.appveyor.com/project/kirbyfan64/appveyor-python. On Sun, Sep 21, 2014 at 5:16 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 21 September 2014 22:47, Ryan Gonzalez <rymg19@gmail.com> wrote:
I'm guessing the appveyor.yml file might look like this:
install: - cinst python - cinst pip - pip install wheel
build: off # It's Python; no building allowed!
test_script: - py.test # or whatever to run tests
deploy_script: - python setup.py sdist bdist_wheel upload
The one I'm working from (cookiecutter) is more complex - essentially because it manually installs Python etc. I'd not seen cinst before, but from a quick search I see that's chocolatey. So yes, something like that. Can you specify which version of Python cinst installs? You'd actually want to make sure you had all the versions of Python you supported installed.
Also, you probably couldn't do the upload in deploy_script unless you were willing to store your credentials in AppVeyor.
But essentially, it's not hard to set up, AFAICT. Paul
-- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/
Also, you might find this interesting: http://kirbyfan64.github.io/posts/using-appveyor-to-distribute-python-wheels... . On Sun, Sep 21, 2014 at 5:16 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 21 September 2014 22:47, Ryan Gonzalez <rymg19@gmail.com> wrote:
I'm guessing the appveyor.yml file might look like this:
install: - cinst python - cinst pip - pip install wheel
build: off # It's Python; no building allowed!
test_script: - py.test # or whatever to run tests
deploy_script: - python setup.py sdist bdist_wheel upload
The one I'm working from (cookiecutter) is more complex - essentially because it manually installs Python etc. I'd not seen cinst before, but from a quick search I see that's chocolatey. So yes, something like that. Can you specify which version of Python cinst installs? You'd actually want to make sure you had all the versions of Python you supported installed.
Also, you probably couldn't do the upload in deploy_script unless you were willing to store your credentials in AppVeyor.
But essentially, it's not hard to set up, AFAICT. Paul
-- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/
The following python appveyor examples might be useful: - https://github.com/rmcgibbo/python-appveyor-conda-example - https://github.com/ogrisel/python-appveyor-demo -Robert On Sun, Sep 21, 2014 at 3:50 PM, Ryan Gonzalez <rymg19@gmail.com> wrote:
Also, you might find this interesting: http://kirbyfan64.github.io/posts/using-appveyor-to-distribute-python-wheels... .
On Sun, Sep 21, 2014 at 5:16 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 21 September 2014 22:47, Ryan Gonzalez <rymg19@gmail.com> wrote:
I'm guessing the appveyor.yml file might look like this:
install: - cinst python - cinst pip - pip install wheel
build: off # It's Python; no building allowed!
test_script: - py.test # or whatever to run tests
deploy_script: - python setup.py sdist bdist_wheel upload
The one I'm working from (cookiecutter) is more complex - essentially because it manually installs Python etc. I'd not seen cinst before, but from a quick search I see that's chocolatey. So yes, something like that. Can you specify which version of Python cinst installs? You'd actually want to make sure you had all the versions of Python you supported installed.
Also, you probably couldn't do the upload in deploy_script unless you were willing to store your credentials in AppVeyor.
But essentially, it's not hard to set up, AFAICT. Paul
-- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Sun, Sep 21, 2014 at 5:36 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Offering to help in building them would likely be appreciated, as many projects may not have access to systems that allow them to build Windows binaries (alternatively, if Daniel approached the PSF for assistance in providing Windows binaries, we can generally provide some help in situations like that, especially to folks that have already been accepted as CPython core developers).
Help building Windows binaries would definitely be appreciated. The only Windows machine in my life runs an entertainment center and isn't set up to build anything. Who should I contact at the PSF? -- Daniel Stutzbach
participants (7)
-
Antoine Pitrou -
Daniel Stutzbach -
Ian Cordasco -
Nick Coghlan -
Paul Moore -
Robert McGibbon -
Ryan Gonzalez