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

61–70 of 215 posts

Re: How to make a Python package in 2021

#61

Post by staticassertion »

blondin wrote: post #46
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.

yea, it is. but it's a sane thing to do. recommending poetry for a beginner is a bad idea. (nothing against that package). python is a mature, old, software system. three times older than go or rust. way older than zig. these modern languages have learned from the field as a whole and implemented tools that people are taking for granted nowadays. as with any mature software system, people & companies have established…

Well, Python did set up a standard - pyproject.toml. And it's what poetry uses. It's just, uh, "light".

Re: How to make a Python package in 2021

#62

Post by monsieurbanana »

smnrchrds wrote: post #50
tcbasche wrote: post #24

Earlier quoted context omitted.

How does it compare to pipenv?

Pipenv only targets applications; Poetry targets both applications and libraries. Pipenv has quite some drama behind it that I do not want to get into; in contrast, Poetry's development has been quite professional. Pipenv enjoys better tool support, e.g. it is recognized and supported by VS Code; but Poetry does not have the same level of support.

I don't know anything about pipenv drama, so by morbid curiosity I looked for it and this is the first thing I found:

https://github.com/pypa/pipenv/issues/2228

This is one of the most ridiculous issues I've read. If the rest of the "drama" is like that, then eh.

Re: How to make a Python package in 2021

#63

Post by xapata »

staticassertion wrote: post #60
xapata wrote: post #57

Earlier quoted context omitted.

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.

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.

Re: How to make a Python package in 2021

#64

Post by erezsh »

carreau wrote: post #10
mikepurvis wrote: post #2

I hadn't heard of flit, it does seem like it's not brand new on the scene, however it is primarily a single author, so expect a tool which is opinionated and for which the opinions may not necessarily reflect a broad consensus: https://github.com/takluyver/flit/graphs/contributors With a title like this, I'd be expecting to see an article describing the latest tools and recommendations from the PyPA, which are here:…

Thomas is well know as one of the maintainer of IPython and Jupyter, and developed flit while working on the pep for pyproject.toml and the pip backend allowing things like python -m build. Though `python -m build` only works _if_ you use something like flit or setup.py in the backend to do build the package and hence why you can set flit as a build-backend. So yes, flit is one of the latest tool, and yes it is one o…

How does flit compare to poetry? The seem to be both doing the same thing, and in a very similar way.

Re: How to make a Python package in 2021

#66

Post by divbzero »

staticassertion wrote: post #60
xapata wrote: post #57

Earlier quoted context omitted.

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.

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

Re: How to make a Python package in 2021

#67

Post by goerz »

staticassertion wrote: post #61
blondin wrote: post #46

Earlier quoted context omitted.

yea, it is. but it's a sane thing to do. recommending poetry for a beginner is a bad idea. (nothing against that package). python is a mature, old, software system. three times older than go or rust. way older than zig. these modern languages have learned from the field as a whole and implemented tools that people are taking for granted nowadays. as with any mature software system, people & companies have established…

Well, Python did set up a standard - pyproject.toml. And it's what poetry uses. It's just, uh, "light".

It's also not ready yet, missing critical features like editable installs. Right now, you still need a shim setup.py. Until pyproject.toml can actually replace setupy.py, I see little incentive to start using it: It's just one more file to add. The one exception is if the package actually has build requirements, e.g. for Cython modules.

Re: How to make a Python package in 2021

#68

Post by kristjansson »

rtpg wrote: post #6

The recommendation to set up a Makefile on top of tox is a bit odd to be honest. Tox basically "just works", and you can do things like pass stuff to `pytest` by setting up `{posargs}` in the tox config (see [0]) I do feel like tox gets a bad rap despite having a complete feature set. I think a part of it is that the documentation is complete but not organized in the "Tox user"'s perspective, so for someone who shows…

I’d argue the counterpoint actually: Writing Makefile targets for common commands significantly improves usability and ergonomics, especially when they follow common idioms (make test, make build, make install, ...).

The recipes for each target describe not only how a project intends to run each tool, but which tools it intends to run. Instead of having to know that this project runs tests under tox, while that one runs only under pytest, we can run ‘make test’ in each, and count on the recipe doing the Right Thing.

That consistency across projects makes it much easier for someone to get started on a new project (or to remember how the pieces fit together on your own project from a few months ago)

Re: How to make a Python package in 2021

#69

Post by knome »

dagenix wrote: post #59
zomglings wrote: post #15

Earlier quoted context omitted.

Iteratively. You don't need to solve all those problems at once. Version pinning can be done in setup.py using the same syntax you would see in a requirements.txt file. You should be very conservative when pinning versions in a library, though. You can lean on your ci tool (eg. Github actions) to handle testing, hash checking, credential management, etc. But I recommend all of this start as a bunch of locally runnabl…

> Version pinning can be done in setup.py using the same syntax you would see in a requirements.txt file The problem with this approach is that it doesn't handle transitive dependencies well. Say you depend on version 1.4.6 of a particular library. And then that library depends on version >= 2 of some other library. When you install your package, you know that you'll get version 1.4.6 of the first library but have no…

Seems like a solid argument for a switch to use go's minimal version selection

the version selected during a build is the one with the most minimal version that satisfies all other constraints. this means if you have libA that needs dep>=1.1 and libB that needs dep>=1.3, you get dep=1.3 even if dep1.9 is out. your build never changes because of a new version release, as long as they release with proper semantic versioning. if you later include libC that needs dep>=1.8, you'll get that version. but because you changed your immediate dependencies, not due to a surprise down the dependency line.

https://research.swtch.com/vgo-principles

Re: How to make a Python package in 2021

#70

Post by anaganisk »

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.

Default way is pip freeze which I feel is too verbose, is tracking every dependency of django worth it?
Post reply on HN