Am 01.11.2016 um 10:50 schrieb Nick Coghlan:
On 1 November 2016 at 17:30, Thomas Güttler
<guettl...@thomas-guettler.de> wrote:
Am 17.09.2016 um 12:29 schrieb Nick Coghlan:
Hi folks,
Prompted by a few posts I read recently about the current state of the
Python packaging ecosystem, I figured it made sense to put together an
article summarising my own perspective on the current state of things:
http://www.curiousefficiency.org/posts/2016/09/python-packaging-ecosystem.html
Thank you for this summarizing article. Yes, a lot was done during the last
months.
I liked the part "My core software ecosystem design philosophy" a lot, since
it explains that both parties (software consumer and software publisher) want
it to be simple and easy.
About conda: if pip and conda overlap in some point. Why not implement
this in a reusable library which gets used by conda and pip?
For the parts where they genuinely overlap, conda is already able to
just use pip, or else the same libraries that pip uses. For the
platform management pieces (SAT solving for conda repositories,
converting PyPI packages to conda ones, language independent
environment management), what conda does is outside the scope of what
pip supports anyway.
About funding: Looking for more income is one way to solve this. Why not
look into the other direction: How to reduce costs?
Thanks to donated infrastructure, the direct costs to the PSF are
incredibly low already. Donald went into some detail on that in
https://caremad.io/posts/2016/05/powering-pypi/ and that's mostly
still accurate (although his funded role with HPE ended recently)
Heading "Making the presence of a compiler on end user systems optional". Here
I just can say: Thank you very much. I guess it was a lot of hard work to
make this all simple and easy for the software consumers and publishers. Thank
you.
I wrote some lines, but I deleted my thoughts about the topic "Automating wheel
creation", since
I am a afraid it could raise bad mood in this list again. That's not my goal.
I currently see 3 main ways that could eventually happen:
- the PSF sorts out its general sustainability concerns to the point
where it believes it can credibly maintain such a service on the
community's behalf
- the conda-forge folks branch out into offering wheel building as
well (so it becomes a matter of "publish your Python projects for the
user level conda platform, get platform independent Python wheels as
well")
- someone builds such a service independently of the current PyPI
infrastructure team, and convinces package publishers to start using
it
There's also a 4th variant, which is getting to a point where someone
figures out a pushbutton solution for a build pipeline in a public
PaaS that offers a decent free tier. This is potentially one of the
more promising options, since it means the sustainability risks
related to future growth in demand accrue to the PaaS providers,
rather than to the PSF. However, it's somewhat gated on the Warehouse
migration, since you really want API token support for that kind of
automation, which is something the current PyPI code base doesn't
have, and isn't going to gain.
I like this 4th variant. I guess most companies which use Python
in a professional way already run a own pypi server.
I am unsure if a public PaaS for this would exist. Maybe a script
which runs a container on linux is enough. At least enough to
build linux-only wheels. I guess most people have root access
to a linux server somewhere.
Regards,
Thomas
--
Thomas Guettler http://www.thomas-guettler.de/
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
