The Python community has considered an "official" packaging tool in the past, but in those conversations found that the community had too many preferences to find a good compromise. That's the trouble with having a highly diverse set of uses and integrations, and lots of legacy.
If you're curious, the email threads about Conda and defining wheels are interesting.
Re:How to make a Python package in 2021
by staticassertion on Thursday April 08, 2021 @12:42AM
(#26735157)
I feel like the entire point of a BDFL is that they can just ignore this sort of thing and make the hard call, but it never happened.
Maybe it could still happen? It seems like a super high value challenge that the BDFL could take on: build out the official set of tools (setup.py, twine, virtualenv, pip) to support features that make people seek out alternatives (pyproject.toml, poetry, flit, conda, pyenv, pipenv).
I realize this is controversial but from reading the docs I really thought Pipenv was the official solution. Took me a while to realize this wasn't the case.
I went through the same progression, thinking pipenv was the official solution before deciding it wasn’t. Then, just now, I realized that pipenv [1] is currently owned by the Python Packaging Authority (PyPA) who also owns pip [2] and virtualenv [3]. I don’t know the right answer but this illustrates the confusion of not coalescing around an official solution.
[1]: https://github.com/pypa/pipenv
What happened was that Kenneth Reitz socially-engineered his way into the PyPA to get his tool blessed. The community lashed out (since the tool had obvious shortcomings and a somewhat dubious development process) and recommendations were softened. Eventually the PyPA had to take over pipenv when Reitz had other issues, and they are now forever burdened with what is a bit of a dud.
As I understand it, that was to prevent bad behavior rather than to signal approval.
Re:How to make a Python package in 2021
by staticassertion on Thursday April 08, 2021 @01:46AM
(#26735464)
I think the time has passed, both in terms of there no longer being a BDFL, as well as Python passing a point where the call can be made.
Sadly I bet you’re right on this. My small sliver of hope is that Guido van Rossum’s ideas to “make using Python better” [1] include better packaging.
Re:How to make a Python package in 2021
by takluyver on Thursday April 08, 2021 @04:31AM
(#26736412)
There are quite a lot of people working on better packaging (look at the Python discourse forum, for instance), but this is not really a topic that Guido has got involved in, at least in the time I've been paying attention.
But with or without a BDFL, one packaging tool to rule them all is a pretty tall order. The needs of a package like scipy, which incorporates C & Fortran code, are pretty different from something like requests. And different communities using Python have their own entrenched tools and techniques. It takes more than someone saying "Foo is officially blessed" to shift that, even if everyone respects the person saying that.
Re:How to make a Python package in 2021
by arthurcolle on Thursday April 08, 2021 @02:00AM
(#26735550)
Is there a new BDFL? I remember reading this half a year ago or so https://hub.packtpub.com/why-guido-van-rossum-quit/
On the whole, Guido's career as a BDFL was astoundingly effective. Maybe he made the right call. It'd have been a terrible idea to alienate the science community just when data science was taking off as a field.
Re:How to make a Python package in 2021
by staticassertion on Thursday April 08, 2021 @01:51AM
(#26735500)
I'm not disagreeing, but I am curious if you have anything specific you would point to with regards to Guido's role being successful. I'm just ignorant really, it's not intended to be a leading question at all.
Too many things to answer here. The easiest is to point to the popularity of the language. He's made decisions I disagree with, but I can't argue with success.
I don't know how much the original author had to do with Python's success in the last 20 years. The success of Python in data science is because of NumPy/Scipy/Pandas. Things like packaging that needed leadership never got any.
The leadership was that the science community would benefit from a science-specific tool, like Conda, and that making one ring to rule them all would be too difficult.
Also, yes, Guido and many other early contributers have been been active for 30ish years.
Conda isn't really science specific, just like pip isn't webdev specific.
The result isn't, but the motivation was. And have you noticed who is using which tool?
> The success of Python in data science is because of NumPy/Scipy/Pandas.
And NumPy/Scipy/Pandas exist (and are successful) because...? /s
Re:How to make a Python package in 2021
by regularfry on Thursday April 08, 2021 @10:32AM
(#26739185)
Rubygems, and then Bundler, followed the same pattern. Neither was batteries-included, both were unofficial community efforts. Bundler directly influenced cargo.
Leiningen is the weird one where people did actually settle fairly well around an unofficial solution in the absence of an official one. I think the norm with languages that forego official tooling is closer to what we've seen in Python.