ANNOUNCE: Sunsetting of uploading to the legacy PyPI/TestPyPI
Hello All! As most people are aware, there has been an effort under way to rewrite PyPI in order to solve a lot of long standing problems. For those who aren't aware, that is currently available at https://pypi.org/ and it uses the same database that "Legacy" PyPI does, so the two are essentially just different views over the same data. For a awhile now, Python, setuptools, and twine have all defaulted to using this new code base for uploading artifacts to PyPI. Now that we've gotten some testing of that code base, the infrastructure team and myself feel comfortable directing everyone to using the new endpoint and we're planning on shutting down uploads to Legacy PyPI. If you're using the latest versions of Python, setuptools, or twine and you have not put an explicit URL in your ~/.pypirc file, then there's nothing you should need to do. If you are not, then you should ideally upgrade to the latest version of whatever tool you're using to upload (the preferred tool is twine) and edit your ~/.pypirc so that it removes any explicit mention of an URL. Thus it should look something like: [distutils] index-servers = pypi [pypi] username:yourusername password:yourpassword If for some reason you're not able to update to the newest version of your upload tool, then you can configure it to upload to the new code base by switching the URL to use https://upload.pypi.org/legacy/ instead of https://pypi.python.org/pypi. Thus your ~/.pypirc would then become: [distutils] index-servers = pypi [pypi] repository:https://upload.pypi.org/legacy/ username:yourusername password:yourpassword For those of you who are using TestPyPI, that will also be affected, and the required URL for the new upload endpoint for TestPyPI is https://test.pypi.org/legacy/. We plan to disable uploads to legacy PyPI on July 3rd, 2017 so any configuration change will need to be made before that date. In addition, we plan to have a "brownout" on June 29th where we will shut the legacy endpoint down for that day. For TestPyPI the change to disable uploads to legacy will be made in the next couple of days, likely this weekend. As part of the error message that users will get when attempting to upload to legacy PyPI, we will include a link to a page that details how to ensure that they are using the new code base and not the legacy code base. Thanks everyone! — Donald Stufft
Donald Stufft <donald@stufft.io> writes:
As most people are aware, there has been an effort under way to rewrite PyPI in order to solve a lot of long standing problems. For those who aren't aware, that is currently available at https://pypi.org/ and it uses the same database that "Legacy" PyPI does, so the two are essentially just different views over the same data.
Great, thank you all for the effort! As I'm used to keep an eye from time to time on https://pypi.python.org/pypi, just to spot relevant upgrades, or see something new that catches my attention, I wonder if the new interface offers a similar view, or some kind of RSS feed, with more than the five "New Releases" box. Should I change my habits? Thanks again, ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. lele@metapensiero.it | -- Fortunato Depero, 1929.
On Jun 22, 2017, at 1:00 PM, Lele Gaifax <lele@metapensiero.it> wrote:
Donald Stufft <donald@stufft.io> writes:
As most people are aware, there has been an effort under way to rewrite PyPI in order to solve a lot of long standing problems. For those who aren't aware, that is currently available at https://pypi.org/ and it uses the same database that "Legacy" PyPI does, so the two are essentially just different views over the same data.
Great, thank you all for the effort!
As I'm used to keep an eye from time to time on https://pypi.python.org/pypi, just to spot relevant upgrades, or see something new that catches my attention, I wonder if the new interface offers a similar view, or some kind of RSS feed, with more than the five "New Releases" box.
Can you open an issue on https://github.com/pypa/warehouse? <https://github.com/pypa/warehouse?> I think we could probably add something along this lines. At a minimum an RSS feed should be easy (which I think we already have, but it may not be a great one) but I’m thinking maybe the search interface could allow ordering by last update too, then you can search for nothing and get the most recently updated things across the entire site, but it would also let you search for say “Django” and get the most recently updated things that have to do with Django. — Donald Stufft
On Jun 22, 2017, at 1:37 PM, Donald Stufft <donald@stufft.io> wrote:
On Jun 22, 2017, at 1:00 PM, Lele Gaifax <lele@metapensiero.it <mailto:lele@metapensiero.it>> wrote:
Donald Stufft <donald@stufft.io <mailto:donald@stufft.io>> writes:
As most people are aware, there has been an effort under way to rewrite PyPI in order to solve a lot of long standing problems. For those who aren't aware, that is currently available at https://pypi.org/ <https://pypi.org/> and it uses the same database that "Legacy" PyPI does, so the two are essentially just different views over the same data.
Great, thank you all for the effort!
As I'm used to keep an eye from time to time on https://pypi.python.org/pypi <https://pypi.python.org/pypi>, just to spot relevant upgrades, or see something new that catches my attention, I wonder if the new interface offers a similar view, or some kind of RSS feed, with more than the five "New Releases" box.
Can you open an issue on https://github.com/pypa/warehouse? <https://github.com/pypa/warehouse?> I think we could probably add something along this lines. At a minimum an RSS feed should be easy (which I think we already have, but it may not be a great one) but I’m thinking maybe the search interface could allow ordering by last update too, then you can search for nothing and get the most recently updated things across the entire site, but it would also let you search for say “Django” and get the most recently updated things that have to do with Django.
Oh never mind, this already works: https://pypi.org/search/?q=&o=-created <https://pypi.org/search/?q=&o=-created> — Donald Stufft
Donald Stufft <donald@stufft.io> writes:
Oh never mind, this already works: https://pypi.org/search/?q=&o=-created <https://pypi.org/search/?q=&o=-created>
Thank you! Even if a bit more verbose than the old interface, being able to look back several days is a bonus, I will relax my compulsive visits :-) ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. lele@metapensiero.it | -- Fortunato Depero, 1929.
On Jun 22, 2017, at 2:10 PM, Lele Gaifax <lele@metapensiero.it> wrote:
Donald Stufft <donald@stufft.io> writes:
Oh never mind, this already works: https://pypi.org/search/?q=&o=-created <https://pypi.org/search/?q=&o=-created>
Thank you! Even if a bit more verbose than the old interface, being able to look back several days is a bonus, I will relax my compulsive visits :-)
Yea! The only caveat is right now the search index isn’t updated on demand (it’s on my TODO list) so there is some lag time. — Donald Stufft
First of all, congrats to everybody for the successful deploy! A little less than an year ago we had the following exchange: Donald Stufft <donald@stufft.io> writes:
On Jun 22, 2017, at 1:37 PM, Donald Stufft <donald@stufft.io> wrote:
On Jun 22, 2017, at 1:00 PM, Lele Gaifax <lele@metapensiero.it> wrote:
As I'm used to keep an eye from time to time on https://pypi.python.org/pypi <https://pypi.python.org/pypi>, just to spot relevant upgrades, or see something new that catches my attention, I wonder if the new interface offers a similar view, or some kind of RSS feed, with more than the five "New Releases" box.
Can you open an issue on https://github.com/pypa/warehouse? <https://github.com/pypa/warehouse?> I think we could probably add something along this lines. At a minimum an RSS feed should be easy (which I think we already have, but it may not be a great one) but I’m thinking maybe the search interface could allow ordering by last update too, then you can search for nothing and get the most recently updated things across the entire site, but it would also let you search for say “Django” and get the most recently updated things that have to do with Django.
Oh never mind, this already works: https://pypi.org/search/?q=&o=-created
Today, looking around on the new site, I realized that the above does not work anymore. Is there any alternative? Thanks&bye, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. lele@metapensiero.it | -- Fortunato Depero, 1929.
On 17 April 2018 at 08:33, Lele Gaifax <lele@metapensiero.it> wrote:
Oh never mind, this already works: https://pypi.org/search/?q=&o=-created
Today, looking around on the new site, I realized that the above does not work anymore. Is there any alternative?
I'm not sure of the status of any search syntax changes, but the Warehouse RSS feeds are covered at https://warehouse.readthedocs.io/api-reference/feeds/ (those feeds did exist on Legacy PyPI, but the Warehouse implementation tidies up some inconsistencies in the data they provide) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Donald Stufft <donald@stufft.io> writes:
[…] rewrite PyPI in order to solve a lot of long standing problems. For those who aren't aware, that is currently available at https://pypi.org/
Thank you to everyone involved in bringing this to fruition!
For a awhile now, Python, setuptools, and twine have all defaulted to using this new code base for uploading artifacts to PyPI.
Where can we find the exact versions of each that default to ‘pypi.org’ for uploads?
[‘pypi.org’] uses the same database that "Legacy" PyPI does, so the two are essentially just different views over the same data.
At what point does the big red warning banner (“ This is a pre-production deployment of Warehouse.”) come down? What is the cross-over period: ‘pypi.org’ as the primary recommendation, while ‘pypi.python.org’ continues to work? -- \ “You can never entirely stop being what you once were. That's | `\ why it's important to be the right person today, and not put it | _o__) off until tomorrow.” —Larry Wall | Ben Finney
On 23 June 2017 at 20:44, Ben Finney <ben+python@benfinney.id.au> wrote:
Donald Stufft <donald@stufft.io> writes:
[‘pypi.org’] uses the same database that "Legacy" PyPI does, so the two are essentially just different views over the same data.
At what point does the big red warning banner (“ This is a pre-production deployment of Warehouse.”) come down?
For non-logged-in use, pretty much anytime, but a lot of the logged-in publisher pages aren't complete enough to allow a full migration yet.
What is the cross-over period: ‘pypi.org’ as the primary recommendation, while ‘pypi.python.org’ continues to work?
Full migration = pypi.python.org becomes a CNAME for pypi.org. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Nick Coghlan <ncoghlan@gmail.com> writes:
On 23 June 2017 at 20:44, Ben Finney <ben+python@benfinney.id.au> wrote:
What is the cross-over period: ‘pypi.org’ as the primary recommendation, while ‘pypi.python.org’ continues to work?
Full migration = pypi.python.org becomes a CNAME for pypi.org.
Thank you, that is the state at the *end* of the cross-over period. But that's not what I asked. What is the cross-over period, during which we have ‘pypi.org’ as the primary recommendation, while ‘pypi.python.org’ continues to work as it currently does? -- \ “If you always want the latest and greatest, then you have to | `\ buy a new iPod at least once a year.” —Steve Jobs, MSNBC | _o__) interview 2006-05-25 | Ben Finney
On Jun 23, 2017, at 6:44 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
Donald Stufft <donald@stufft.io> writes:
[…] rewrite PyPI in order to solve a lot of long standing problems. For those who aren't aware, that is currently available at https://pypi.org/
Thank you to everyone involved in bringing this to fruition!
For a awhile now, Python, setuptools, and twine have all defaulted to using this new code base for uploading artifacts to PyPI.
Where can we find the exact versions of each that default to ‘pypi.org’ for uploads?
Umm. Twine 1.8.0, Python 3.4.6, 3.5.3, 3.6.0, Not sure on 2.7, the Github interface seems to be broken and not listing the tags for that one. Essentially it was committed 11 months ago and whatever releases came after that.
[‘pypi.org’] uses the same database that "Legacy" PyPI does, so the two are essentially just different views over the same data.
At what point does the big red warning banner (“ This is a pre-production deployment of Warehouse.”) come down?
Roughly whenever we have Warehouse hosted in a place that can handle that 30-40tb/month that Rackspace says our origin servers receive that would come Warehouse’s way at that point. PyPI is massively read heavy to an absurd degree, so the traffic from uploads is relatively small compared to the traffic from downloads, and currently Warehouse is not hosted in a way to handle our read traffic. The other thing the banner accomplishes is to provide warning that you may see weirdness in the UI (for example, hardcoded demo data etc) and to indicate that this is normal and please don’t file bugs for it.
What is the cross-over period: ‘pypi.org’ as the primary recommendation, while ‘pypi.python.org’ continues to work?
I’m not sure what specifically you’re asking here? Are you looking for how long they’re both going to remain active or the process we’re going to migrate things over with? Or something else? — Donald Stufft
Donald Stufft <donald@stufft.io> writes:
Umm. Twine 1.8.0, Python 3.4.6, 3.5.3, 3.6.0, Not sure on 2.7, the Github interface seems to be broken and not listing the tags for that one.
Thanks. What version of Setuptools is needed? I'm hoping that the above list will be prominently published with the documentation that we point people toward for announcing we should be using those tools. (“Use the latest version of the tool” doesn't cut it; we'll need to check what versions our operating system provides, and know whether it's in or out of compliance with the above list.)
What is the cross-over period: ‘pypi.org’ as the primary recommendation, while ‘pypi.python.org’ continues to work?
I’m not sure what specifically you’re asking here? Are you looking for how long they’re both going to remain active or the process we’re going to migrate things over with? Or something else?
I'm working on the assumption the sequence will include: * Now: Uploading to ‘pypi.python.org’ is officially recommended; it goes to the same data store as uploading to ‘pypi.org’. Both work fine. * Crossover: Uploading to ‘pypi.org’ is officially recommended; it goes to the same data store as uploading to ‘pypi.python.org’. Both work fine. * Warehouse Rules Alone: Uploading to ‘pypi.org’ is recommended, because uploading to ‘pypi.python.org’ doesn't work. So, what is the period – when does it start and when does it end – that the Crossover state will active? -- \ “… correct code is great, code that crashes could use | `\ improvement, but incorrect code that doesn’t crash is a | _o__) horrible nightmare.” —Chris Smith, 2008-08-22 | Ben Finney
On Fri, Jun 23, 2017 at 9:43 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
So, what is the period – when does it start and when does it end – that the Crossover state will active?
The time of officially recommending "pypi.org" was Sept 2017 when setuptools v27 was released which switched the default. https://setuptools.readthedocs.io/en/latest/history.html#v27-0-0 I think Donald is saying that period of them both working will be over on July 3rd at which point only pypi.org will work. As far as which UI is recommended to manage your packages and for end-users to view things - I'm not sure about that timeline. For viewing packages I've been using pypi.org for a while now with minimal issues but it still has no management features in the UI.
On Jun 23, 2017, at 11:11 AM, Michael Merickel <mmericke@gmail.com> wrote:
On Fri, Jun 23, 2017 at 9:43 AM, Ben Finney <ben+python@benfinney.id.au <mailto:ben+python@benfinney.id.au>> wrote: So, what is the period – when does it start and when does it end – that the Crossover state will active?
The time of officially recommending "pypi.org <http://pypi.org/>" was Sept 2017 when setuptools v27 was released which switched the default.
https://setuptools.readthedocs.io/en/latest/history.html#v27-0-0 <https://setuptools.readthedocs.io/en/latest/history.html#v27-0-0>
I think Donald is saying that period of them both working will be over on July 3rd at which point only pypi.org <http://pypi.org/> will work.
As far as which UI is recommended to manage your packages and for end-users to view things - I'm not sure about that timeline. For viewing packages I've been using pypi.org <http://pypi.org/> for a while now with minimal issues but it still has no management features in the UI.
Basically this yea. — Donald Stufft
On 24 June 2017 at 01:11, Michael Merickel <mmericke@gmail.com> wrote:
As far as which UI is recommended to manage your packages and for end-users to view things - I'm not sure about that timeline. For viewing packages I've been using pypi.org for a while now with minimal issues but it still has no management features in the UI.
Thanks for that. I better understand Ben's question now, and it made me realise that https://packaging.python.org/guides/tool-recommendations/ is missing a section on "Publishing platform" that explains the migration that is currently in progress and covers what pypi.org currently handles better than pypi.python.org (publishing), which should still use pypi.python.org (downloading due to server bandwidth availability, package management UI), and those where it doesn't matter much which you use (browsing). I've created a PR to add that here: https://github.com/pypa/python-packaging-user-guide/pull/334 Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 24 June 2017 at 15:24, Nick Coghlan <ncoghlan@gmail.com> wrote:
https://packaging.python.org/guides/tool-recommendations/ is missing a section on "Publishing platform" that explains the migration that is currently in progress and covers what pypi.org currently handles better than pypi.python.org (publishing), which should still use pypi.python.org (downloading due to server bandwidth availability, package management UI), and those where it doesn't matter much which you use (browsing).
The new "Publishing Platform Migration" section is now live: https://packaging.python.org/guides/tool-recommendations/#publishing-platfor... Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
For reference, I switched the default upload server for flit in version 0.11. On Sat, Jun 24, 2017, at 08:45 AM, Nick Coghlan wrote:
On 24 June 2017 at 15:24, Nick Coghlan <ncoghlan@gmail.com> wrote:
https://packaging.python.org/guides/tool-recommendations/ is missing a section on "Publishing platform" that explains the migration that is currently in progress and covers what pypi.org currently handles better than pypi.python.org (publishing), which should still use pypi.python.org (downloading due to server bandwidth availability, package management UI), and those where it doesn't matter much which you use (browsing).
The new "Publishing Platform Migration" section is now live: https://packaging.python.org/guides/tool-recommendations/#publishing-platfor...
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 24 June 2017 at 18:56, Thomas Kluyver <thomas@kluyver.me.uk> wrote:
For reference, I switched the default upload server for flit in version 0.11.
Oh, I'd also missed that 0.11 published sdists now. Given that, I think we should start recommending flit for new pure Python projects (the lack of sdists was the only thing previously making me hesitant about that), and then add it to the PyPI upload migration list as well. It's also missing an entry in the Key Projects list: https://packaging.python.org/key_projects/ I've filed an issue to discuss that here: https://github.com/pypa/python-packaging-user-guide/issues/336 We should probably add enscons to the Key Projects list as well, since that allows folks the option of using a full pip-installable C/C++ build system as an alternative to setuptools/distutils, so I also filed an issue to discuss that: https://github.com/pypa/python-packaging-user-guide/issues/337 Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
For what it's worth, for the projects that are almost ready to recommend, but not quite there (like Flit per the discussion on issue 336), would it hurt to have an "provisional" area to the key projects list that makes people aware of the projects without "blessing" them as Key Projects. The whole point of that section of the guide is to raise awareness, yes? Well if something like Flit is almost ready, but pending for a small reason or two, why not publish it anyway with some kind of "provision" label or something and an explanation of why the project is important, but not quite yet ready? "Provisional" may not be the best term, couldn't think of a better term at the moment. Just my $0.02. *Randy Syring* Husband | Father | Redeemed Sinner /"For what does it profit a man to gain the whole world and forfeit his soul?" (Mark 8:36 ESV)/ On 06/24/2017 09:15 AM, Nick Coghlan wrote:
On 24 June 2017 at 18:56, Thomas Kluyver <thomas@kluyver.me.uk> wrote:
For reference, I switched the default upload server for flit in version 0.11. Oh, I'd also missed that 0.11 published sdists now.
Given that, I think we should start recommending flit for new pure Python projects (the lack of sdists was the only thing previously making me hesitant about that), and then add it to the PyPI upload migration list as well.
It's also missing an entry in the Key Projects list: https://packaging.python.org/key_projects/
I've filed an issue to discuss that here: https://github.com/pypa/python-packaging-user-guide/issues/336
We should probably add enscons to the Key Projects list as well, since that allows folks the option of using a full pip-installable C/C++ build system as an alternative to setuptools/distutils, so I also filed an issue to discuss that: https://github.com/pypa/python-packaging-user-guide/issues/337
Cheers, Nick.
Randy Syring <randy@thesyrings.us> writes:
[…] would it hurt to have an "provisional" area to the key projects list that makes people aware of the projects without "blessing" them as Key Projects.
It might hurt, yes. I am already quite confused by what is meant to be done in the Brave New World described in this thread. Pointing to a document that gives a set of tools is helpful – now I have only the confusion of figuring out whether all my development and deployment environments can use those – but that document becomes *less* useful as you add more decisions I need to make.
The whole point of that section of the guide is to raise awareness, yes?
That describes the purpose of an announcement like this. I'm now aware of the change that's looming. On the conitrary, the point of the section of the guide, for a user like me, is to *simplify* the actions I need to take to survive the transition. Adding more options to decide between, however well-intentioned, will work against that purpose. -- \ “You could augment an earwig to the point where it understood | `\ nuclear physics, but it would still be a very stupid thing to | _o__) do!” —The Doctor, _The Two Doctors_ | Ben Finney
On 25 June 2017 at 01:18, Randy Syring <randy@thesyrings.us> wrote:
For what it's worth, for the projects that are almost ready to recommend, but not quite there (like Flit per the discussion on issue 336), would it hurt to have an "provisional" area to the key projects list that makes people aware of the projects without "blessing" them as Key Projects. The whole point of that section of the guide is to raise awareness, yes? Well if something like Flit is almost ready, but pending for a small reason or two, why not publish it anyway with some kind of "provision" label or something and an explanation of why the project is important, but not quite yet ready?
The key projects list is already aimed more at folks wanting to dive into the details of how PyPA and the Python packaging ecosystem actually work in practice (e.g. packaging and distlib are both listed, and those are really only relevant to folks writing their own packaging related tools). The "definitely relevant to end users" list is the one at https://packaging.python.org/guides/tool-recommendations/ (and after discussing the idea with Thomas, we're not going to add flit there until after its 1.0 release) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
* Donald Stufft <donald@stufft.io>, 2017-06-23, 10:21:
Where can we find the exact versions of each that default to ‘pypi.org’ for uploads?
Umm. Twine 1.8.0, Python 3.4.6, 3.5.3, 3.6.0, Not sure on 2.7,
$ git tag --contains=7127b62702bd50bf44138e6f57334887cbcb5ca8 v2.7.13rc1 v2.7.13 -- Jakub Wilk
On Jun 22, 2017, at 12:32 PM, Donald Stufft <donald@stufft.io> wrote:
For TestPyPI the change to disable uploads to legacy will be made in the next couple of days, likely this weekend.
This is done now. Tomorrow we’ll deploy it to real PyPI for the day, but it will then be reverted until July 3rd. — Donald Stufft
On Jun 28, 2017, at 10:03 AM, Donald Stufft <donald@stufft.io> wrote:
On Jun 22, 2017, at 12:32 PM, Donald Stufft <donald@stufft.io <mailto:donald@stufft.io>> wrote:
For TestPyPI the change to disable uploads to legacy will be made in the next couple of days, likely this weekend.
This is done now. Tomorrow we’ll deploy it to real PyPI for the day, but it will then be reverted until July 3rd.
This is done on PyPI now, tomorrow I’ll revert it until July 3rd. — Donald Stufft
On Jun 30, 2017, at 10:48 AM, Donald Stufft <donald@stufft.io> wrote:
On Jun 29, 2017, at 12:09 PM, Donald Stufft <donald@stufft.io <mailto:donald@stufft.io>> wrote:
This is done on PyPI now, tomorrow I’ll revert it until July 3rd.
Upload API is re-enabled until July 3rd.
Upload API is now dead for good. — Donald Stufft
Hi, Would it be possible to also add scikit-build to the list of key projects ? See http://scikit-build.org and https://blog.kitware.com/18772-2/ Thanks Jc On Jul 3, 2017 12:50 PM, "Donald Stufft" <donald@stufft.io> wrote: On Jun 30, 2017, at 10:48 AM, Donald Stufft <donald@stufft.io> wrote: On Jun 29, 2017, at 12:09 PM, Donald Stufft <donald@stufft.io> wrote: This is done on PyPI now, tomorrow I’ll revert it until July 3rd. Upload API is re-enabled until July 3rd. Upload API is now dead for good. — Donald Stufft _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
What list of key projects? Sent from my iPhone
On Jul 17, 2017, at 9:57 AM, Jean-Christophe Fillion-Robin <jchris.fillionr@kitware.com> wrote:
Hi,
Would it be possible to also add scikit-build to the list of key projects ?
See http://scikit-build.org and https://blog.kitware.com/18772-2/
Thanks Jc
On Jul 3, 2017 12:50 PM, "Donald Stufft" <donald@stufft.io> wrote:
On Jun 30, 2017, at 10:48 AM, Donald Stufft <donald@stufft.io> wrote:
On Jun 29, 2017, at 12:09 PM, Donald Stufft <donald@stufft.io> wrote:
This is done on PyPI now, tomorrow I’ll revert it until July 3rd.
Upload API is re-enabled until July 3rd.
Upload API is now dead for good.
— Donald Stufft
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Hi Donald, Since scikit-build allows to easily build wheels including cython, cpp, c, fortran by both leveraging CMake and nicely integrating with setuptools, I was thinking to add it to the Key Projects list as a non-PyPA project. To avoid spamming the list, I will create a PR similar enscons [1] one. Thanks Jc [1] https://github.com/pypa/python-packaging-user-guide/issues/337 On Mon, Jul 17, 2017 at 10:55 AM, Donald Stufft <donald@stufft.io> wrote:
What list of key projects?
Sent from my iPhone
On Jul 17, 2017, at 9:57 AM, Jean-Christophe Fillion-Robin < jchris.fillionr@kitware.com> wrote:
Hi,
Would it be possible to also add scikit-build to the list of key projects ?
See http://scikit-build.org and https://blog.kitware.com/18772-2/
Thanks Jc
On Jul 3, 2017 12:50 PM, "Donald Stufft" <donald@stufft.io> wrote:
On Jun 30, 2017, at 10:48 AM, Donald Stufft <donald@stufft.io> wrote:
On Jun 29, 2017, at 12:09 PM, Donald Stufft <donald@stufft.io> wrote:
This is done on PyPI now, tomorrow I’ll revert it until July 3rd.
Upload API is re-enabled until July 3rd.
Upload API is now dead for good.
— Donald Stufft
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
-- +1 919 869 8849
participants (9)
-
Ben Finney -
Donald Stufft -
Jakub Wilk -
Jean-Christophe Fillion-Robin -
Lele Gaifax -
Michael Merickel -
Nick Coghlan -
Randy Syring -
Thomas Kluyver