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

Underappreciated challenges with Python packaging

pypackaging-native.github.io

Post reply on HN
Print view View original

21–30 of 75 posts

Re: Underappreciated challenges with Python packaging

#21

Post by selcuka »

ensignavenger wrote: post #12
CJefferson wrote: post #10

I've been planning on packaging a python package recently, and the internet is annoyingly full of guides which are, I think, out of date. They at least suggest quite different things. I just have a single python file, meant to be treated as an executable (no package at present). There are a whole bunch of tests, but that's obviously separate. Any suggestions on modern best practices welcome!

If you are wanting to release it to pypi as a python package, I would personally use Poetry. But your case- a single pure Python package, is a simple case that won't have many problems like are brought up in the article, whatever tool you use. If you want a stand alone executable, I haven't found a good, single, cross platform tool for that yet... seems like there is a separate tool for each platform.

> If you want a stand alone executable, I haven't found a good, single, cross platform tool for that yet.

PyInstaller is cross platform, and arguably good.

Re: Underappreciated challenges with Python packaging

#23

Post by tomrod »

mixmastamyk wrote: post #19
CJefferson wrote: post #10

I've been planning on packaging a python package recently, and the internet is annoyingly full of guides which are, I think, out of date. They at least suggest quite different things. I just have a single python file, meant to be treated as an executable (no package at present). There are a whole bunch of tests, but that's obviously separate. Any suggestions on modern best practices welcome!

Keep it simple and fashion-proof. Been using setup.py for a one-script package for one or two? decades: from setuptools import setup setup( name = 'foobar', scripts = ['foo'], # install a script from current fldr # ... ) A few years ago I had to start using twine to register and upload it to pypi.

Is there a place you recommend where I can learn more about this?

Re: Underappreciated challenges with Python packaging

#24

Post by hot_gril »

groodt wrote: post #3
0x008 wrote: post #2

Python packaging’s greatest challenge is 10 competing tools and standards.

Python packaging gets a lot of criticism. It's a meme. The thing is, it's actually improved dramatically over the years and continues to improve. The problems it solves are very complex if one looks a little below the surface. It is solving different problems to the ecosystems that it's often compared to: golang, rust, java, js.

How is it very different from NodeJS? Cause I find npm way easier to deal with than Python packaging, and it's also dealing with native code. I used Python heavily for 6 years and still have no idea how the packages work as a user trying to install libs; I used to just thrash around till it works. I don't use it anymore at my new job.

The one thing I understand is npm installs everything locally by default (unless you -g), and in Python it's hard to stay local even if you use a venv.

Re: Underappreciated challenges with Python packaging

#28

Post by andrewf »

wiredfool wrote: post #8
short_sells_poo wrote: post #6

Earlier quoted context omitted.

I wonder to what degree these complex problems are self inflicted due to more than a decade of flipflopping between a myriad packaging and environment management solution. In such an environment, you are bound to have so many different approaches between important projects that trying to bring them all under one umbrella becomes next to impossible. What is a python package is relatively well defined, but how you buil…

I'd have to look at numbers to be sure, but I think that the number of popular packages that include compiled libraries is dramatically higher than it was 10 years ago, and that's about when wheels were taking over. The Data/Science stack has really exploded in that time, and it's very heavily skewed towards packaging c/fortran/rust libraries. Previously there was PIL, some database drivers, and numpy was just gettin…

What made it click for me is "Python packaging" means "how to install everything that I want to use from Python."

I wouldn't have considered "how to get BLAS onto a system" to be a "Python packaging" issue, but for people who want to rely on it via scipy/numpy/whatever, it is.

Post reply on HN