Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to make a Python package in 2021

antonz.org

Post reply on HN
Print view View original

81–90 of 215 posts

Re: How to make a Python package in 2021

#81

Post by darthrupert »

zomglings wrote: post #8

The number of extra tools used in this article boggles my mind. Are you writing a simple library? Create a setup.py. Copy paste an existing setup.py and modify it to suit your purposes. Now you have a working, pip installable python package. Want to publish to PyPI? Use twine. It's standard and it's simple. You don't need complicated tooling for simple projects.

I actually think one should do the exact opposite to what you're suggesting. I've experienced modern package management through Cargo and anything below that level now seems like returning to stone age.

In the python ecosystem, poorly defined packages is a wide problem. You never know what you get in the next version upgrade.

So my suggestion: burn all the "simple" python packaging tools in a big fire and move eveything to Poetry today. It will be painful at start but will increase the quality of the ecosystem by a huge margin if just 50% of the projects do this.

Re: How to make a Python package in 2021

#82

Post by saila »

perrygeo wrote: post #14

Why not to make a Python package in 2021. Even as a long time Python user, the packaging ecosystem feels fragmented and error-prone at best. Honestly, it sours the experience of writing Python code knowing you might eventually need to make it work on another computer.

I think for the vast majority of at least pure-Python projects you could just use poetry and upload your packages to PyPI or a private index. You can go from an empty directory to publishing a package within minutes with poetry (although, of course, you probably shouldn't).

Re: How to make a Python package in 2021

#83

Post by mrweasel »

zomglings wrote: post #30
staticassertion wrote: post #23

Earlier quoted context omitted.

TBH as someone trying to use Python professionally it is extremely frustrating that basic things with regards to package management are something you have to iterate towards, as opposed to just being obvious and default.

I sympathize. It is unfortunate that the python community never settled around a tool like leiningen for clojure or cargo for rust or npm for node. What we saw with npm was the entire community iterating towards a feature set and everyone reaping the benefits automatically with npm updates. package-lock.json is a good example of this.

I think the Python community have largely settled on pip, just like the JavaScript community have mostly opted for npm.

Personally I much prefer pip over npm, it feels much more polished.

Re: How to make a Python package in 2021

#84

Post by arthurcolle »

divbzero wrote: post #66
staticassertion wrote: post #60

Earlier quoted context omitted.

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).

Is there a new BDFL? I remember reading this half a year ago or so https://hub.packtpub.com/why-guido-van-rossum-quit/

Re: How to make a Python package in 2021

#85

Post by divbzero »

jolux wrote: post #77
divbzero wrote: post #66

Earlier quoted context omitted.

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

[2]: https://github.com/pypa/pip

[3]: https://github.com/pypa/virtualenv

Re: How to make a Python package in 2021

#86

Post by xapata »

staticassertion wrote: post #79
xapata wrote: post #63

Earlier quoted context omitted.

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.

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.

Re: How to make a Python package in 2021

#87

Post by neolog »

xapata wrote: post #63
staticassertion wrote: post #60

Earlier quoted context omitted.

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.

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.

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.

Re: How to make a Python package in 2021

#88

Post by [deleted] »

jolux wrote: post #77
divbzero wrote: post #66

Earlier quoted context omitted.

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.

[deleted]

Re: How to make a Python package in 2021

#89

Post by xapata »

divbzero wrote: post #85
jolux wrote: post #77

Earlier quoted context omitted.

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 [2]: https://github.c…

As I understand it, that was to prevent bad behavior rather than to signal approval.

Re: How to make a Python package in 2021

#90

Post by xapata »

neolog wrote: post #87
xapata wrote: post #63

Earlier quoted context omitted.

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.

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.

Post reply on HN