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

161–170 of 215 posts

Re: How to make a Python package in 2021

#161

Post by fctorial »

chriswarbo wrote: post #150
fctorial wrote: post #140

Earlier quoted context omitted.

For all the hate nodejs gets, it solved the software packaging problem. That is the sole reason npm ecosystem is so big. I have to say that it probably isn't a fare comparison because python is much older than nodejs. Python package management might very well have been state of the art in 1995.

My impression was that npm does little more than fetch code from the Web and stick it in a 'node_modules' directory. I've even seen npm used for things that aren't even JS, just bunch of files. This approach ends up with multiple, potentially-incompatible versions of the same package in a project. True that's less of a problem in JS, since it's interpreted (deferring imports to runtime) and un(i)typed (no need to che…

> This approach ends up with multiple, potentially-incompatible versions of the same package in a project.

If data generated by one version of a library is being consumed by another version, that's a bug in the code that moves data between them.

Re: How to make a Python package in 2021

#162

Post by oblio »

guggle wrote: post #54
neolog wrote: post #3

Just use Poetry [1]. It's popular and works well. [1] https://python-poetry.org/

That's a 72MB download, and yet another way to fragment the ecosystem. Not something I'd get just to make a package when a default Python setup has recommended tools and everything I need to make and/or install packages.

On the list of priorities for any package manager, download size should be #100 on the list.

If you've solved 1-99 and download size is an issue, you're in heaven already.

Re: How to make a Python package in 2021

#163

Post by francislavoie »

fctorial wrote: post #142
francislavoie wrote: post #43

Earlier quoted context omitted.

I rather just write a bash script. It's the lowest common denominator. Make may not be installed by default in many places and it has some weird syntax quirks that make it annoying to use IMO. Here's an example of how I like to do my "bash scripts that sorta work like make": https://github.com/francislavoie/laravel-websockets-example/... basically each function is a "command", so I do like "./utils start" or whatever…

Please don't write a bash script.

Please elaborate. This is a useless comment without more information.

Re: How to make a Python package in 2021

#165

Post by kkirsche »

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.

Copy from https://github.com/pypa/sampleproject !

Re: How to make a Python package in 2021

#166

Post by vonwoodson »

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.

Comments on this reply seem to have forgotten two key things about python.

1) It’s batteries included. The standard library is a core feature, and it is extensive in order to reduce the number 3rd party library dependencies.

2) “There should be one— and preferably only one —obvious way to do it. Although that way may not be obvious at first unless you're Dutch.” The Pythonic way is to use the standard library, setup.py, pypi, and so on. Python is not Rust, or Node, or Clojure, or anything else. Do it Pythonicly and good things will happen.

In the history of Python, it’s only because of the Zen’s guiding principles and the “come join us” attitude of the community that Python accidentally became “enterprise grade”. It succeeded in spite of the lack of Cargo or NPM, or (shudder) Mavin[, or CI/CD, or 3D game engines, or easy binary package productization, or everything else Python is obviously bad at]; almost precisely because it’s not those things. Python encourages me to get my task done, and all it asks is that I leave the flame wars at the door and embrace it for what it is.

It saddens me to see so many people jump down zomglings throat for making the daring suggestion that Pythonistas use the language as designed. Because, he is absolutely right about this: “Complex is better than complicated.”

Re: How to make a Python package in 2021

#168

Post by lucb1e »

BerislavLopac wrote: post #125
74d-fe6-2c6 wrote: post #108

Can somebody confirm that this is reasonable and state of the art? Or is it just a "look what I can do" type blog post?

I would say it is quite up to date. First, it is using pyproject.toml which is now the standard way to define build requirements for Python packages. Second, its collection of additional (linting etc) tools is pretty solid; there are potential alternatives in few cases (e.g. I would personally use Poetry rather than flit, and wouldn't use make for development scripts) but that is pretty much it.

I've never even heard of pyproject.toml and I open github projects behind packages to vet them (to a minimal degree, but still, making sure it's not a typosquat and still maintained and often also reading a bit of source code) on at least a weekly basis. It's not always python of course, but often enough. Maybe it's just some freak coincidence that I somehow never saw it or just don't recall while really it's mostly everywhere, but this broad statement for something I've never even heard of makes me think of JavaScript and the 'standard framework' that changes every six months.

Re: How to make a Python package in 2021

#169

Post by [deleted] »

toyg wrote: post #126
neolog wrote: post #87

Earlier quoted context omitted.

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 success of Python in data science is because of NumPy/Scipy/Pandas. And NumPy/Scipy/Pandas exist (and are successful) because...? /s

[deleted]

Re: How to make a Python package in 2021

#170

Post by NavinF »

m463 wrote: post #159
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 agree. What I actually like is using the system package manager to install stuff. pacman -s or apt-get install letting multiple packaging systems muck with your system is a recipe for hurt somewhere down the line.

Even more fragmentation? As a dev I'm not going to make packages for anything other than 'pip install' and maybe Ubuntu if you're lucky. I would also heavily discourage distros from shipping ancient buggy versions of the package, which is all distros are good for these days.

Packaging sucks.

Post reply on HN