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

181–190 of 215 posts

Re: How to make a Python package in 2021

#181

Post by remram »

cixinlui wrote: post #130
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.

This is bad advice. Do not create a setup.py for a new package. (Keeping setup.py for an old package can be okay.) The author is correct that you want a tool such as flit or poetry which will work with pyproject.toml. Setting up a basic package will be no harder than using setuptools, and it is much more future-proof. You won't have to copy-paste some other crufty setup config either. It is fair that you don't need a…

Future-proof... Poetry 1.1 broke compatibility with 1.0. 1.1 lockfiles would crash Poetry 1.0, and 1.0 lockfiles would be thrown away by Poetry 1.1.

It does not correctly verify hashes (if at all) [1]. You can't add packages without updating all your dependencies. Monorepos are not supported. PEP-508-compliant Git dependencies cause the tool to crash with TypeError [2].

I think Poetry is the right direction, I use it for everything, but it's not the silver bullet you're painting it to be (yet). It's definitely not on par with Cargo, or maybe even npm.

[1]: https://github.com/python-poetry/poetry/issues/3765 [2]: https://github.com/python-poetry/poetry/issues/3425

Re: How to make a Python package in 2021

#182

Post by 1337shadow »

amarshall wrote: post #178
1337shadow wrote: post #102

Earlier quoted context omitted.

I maintain over 50 public packages with setup.py and most of them have setupmeta, it's great and I would recommend it for all use cases.

Sure, and that’s fine. My statement was based off https://packaging.python.org/tutorials/packaging-projects/ > dynamic metadata [(setup.py)] should be used only as an escape hatch when absolutely necessary.

Dynamic version numbers based on git tags are absolutely necessary to me, to ease my continuous integration practice, that's also what openstack/pbr does amongst probably other things

Re: How to make a Python package in 2021

#183

Post by remram »

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.

I think it's the right direction, and I look forward to Poetry maturing. But right now it has a lot of gotchas, and I would only recommend it for people who are serious about dependency management/compliance/reproducibility.

See details upthread https://news.ycombinator.com/item?id=26739234

Re: How to make a Python package in 2021

#184

Post by schnitzelstoat »

darthrupert wrote: post #81
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 eveyth…

Like the other commenter, I was also expecting them to use Poetry.

It's the best one I've tried so far.

Re: How to make a Python package in 2021

#185

Post by alexgmcm »

say_it_as_it_is wrote: post #144
darthrupert wrote: post #81

Earlier quoted context omitted.

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 eveyth…

I was hoping to see this blog post highlight poetry usage. Any good resource for this? I've already seen the official page.

I quite liked the series of blog posts called Hypermodern Python: https://cjolowicz.github.io/posts/hypermodern-python-01-setu...

Re: How to make a Python package in 2021

#186

Post by cixinlui »

remram wrote: post #181
cixinlui wrote: post #130

Earlier quoted context omitted.

This is bad advice. Do not create a setup.py for a new package. (Keeping setup.py for an old package can be okay.) The author is correct that you want a tool such as flit or poetry which will work with pyproject.toml. Setting up a basic package will be no harder than using setuptools, and it is much more future-proof. You won't have to copy-paste some other crufty setup config either. It is fair that you don't need a…

Future-proof... Poetry 1.1 broke compatibility with 1.0. 1.1 lockfiles would crash Poetry 1.0, and 1.0 lockfiles would be thrown away by Poetry 1.1. It does not correctly verify hashes (if at all) [1]. You can't add packages without updating all your dependencies. Monorepos are not supported. PEP-508-compliant Git dependencies cause the tool to crash with TypeError [2]. I think Poetry is the right direction, I use it…

I didn't say it was a silver bullet... I said "Don't Use setup.py".

Re: How to make a Python package in 2021

#187

Post by 74d-fe6-2c6 »

lucb1e wrote: post #168
BerislavLopac wrote: post #125

Earlier quoted context omitted.

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…

It's actually not too uncommon - mostly due to the rising popularity of poetry.

Re: How to make a Python package in 2021

#188

Post by BerislavLopac »

lucb1e wrote: post #168
BerislavLopac wrote: post #125

Earlier quoted context omitted.

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…

With PEP-518 being 5 years old it's still relatively new, and most tools have implemented the support for it relatively recently. The key introduction article was written exactly one year ago: https://snarky.ca/what-the-heck-is-pyproject-toml/

Re: How to make a Python package in 2021

#189

Post by BerislavLopac »

say_it_as_it_is wrote: post #146
BerislavLopac wrote: post #121

Earlier quoted context omitted.

Using setup.py does not mean "not using extra tools". It depends on setuptools, which is an "extra tools" just like flit (used in the article) or any other tool. In fact, with using only setuptools one will need a whole additional set of tools to manage things like: * virtual environments (granted, venv is now part of the stdlib, but it's still an "extra tool") * publishing to PyPI or another index (twine) * dependen…

Where is there a comprehensive poetry packaging tutorial?

Right here:

    poetry build -f wheel
    poetry publish
You asked for packaging, and that is pretty much it. Of course, setting up a project and its dependencies take a bit more work; the basic intro for that is here: https://python-poetry.org/docs/basic-usage/

Re: How to make a Python package in 2021

#190

Post by BerislavLopac »

toyg wrote: post #138
BerislavLopac wrote: post #127

Earlier quoted context omitted.

> You should be very conservative when pinning versions in a library, though No; you should be very conservative when pinning versions in an application, not in a library. Check this article for the explanation: https://caremad.io/posts/2013/07/setup-vs-requirement/

Anybody familiar with the history of requests knows this is bad advice.

requests is definitely not a good example here. :/
Post reply on HN