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

51–60 of 215 posts

Re: How to make a Python package in 2021

#51

Post by [deleted] »

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…

[deleted]

Re: How to make a Python package in 2021

#53

Post by kbd »

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.

FWIW here's VSCode's issue for supporting Poetry[1] and here's their plan to support it[2]:

[1] https://github.com/microsoft/vscode-python/issues/8372

[2] https://github.com/microsoft/vscode-python/wiki/Support-poet...

Re: How to make a Python package in 2021

#54

Post by guggle »

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.

Re: How to make a Python package in 2021

#55

Post by spondyl »

tcbasche wrote: post #24
neolog wrote: post #3

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

How does it compare to pipenv?

From memory, there was a whole thing where pipenv, created by Kenneth Reitz of requests fame, was misaccurately portrayed as the official successor to pip when that wasn't true

Re: How to make a Python package in 2021

#56

Post by neolog »

bliteben wrote: post #47
acdanger wrote: post #35

Earlier quoted context omitted.

I think pipenv is better for managing non-published Python environments, so there.

pipenv has slightly better support in vscode

> Support for poetry environments is currently our highest upvoted feature request on GitHub.

https://github.com/microsoft/vscode-python/wiki/Support-poet...

Re: How to make a Python package in 2021

#57

Post by xapata »

brundolf wrote: post #45
zomglings wrote: post #30

Earlier quoted context omitted.

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.

Worth noting is that cargo and npm weren't "settled around"; they were developed and presented, from the beginning, alongside the relevant compiler and runtime. There was never a question; the batteries were included. Leiningen is the weird one where people did actually settle fairly well around an unofficial solution in the absence of an official one. I think the norm with languages that forego official tooling is c…

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.

Re: How to make a Python package in 2021

#58

Post by mikepurvis »

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…

The additional context is appreciated— it sounds like this tool is something which is likely to be supported long term, so that at least is good.

Re: How to make a Python package in 2021

#59

Post by dagenix »

zomglings wrote: post #15
neolog wrote: post #11

Earlier quoted context omitted.

How do you handle version pinning? hash checking? CI? testing on multiple platforms? multiple python versions? deployment? credential management? package data? version bumps? Sure, experts know how to do all these things because they spent many days learning them, but I'd rather outsource to a tool.

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 idea what version you'll get of the second library. You can of course pin all the transitive dependencies - except that clutters up the setup.py and is a massive pain to keep up to date as you bump individual dependency versions.

Re: How to make a Python package in 2021

#60

Post by staticassertion »

xapata wrote: post #57
brundolf wrote: post #45

Earlier quoted context omitted.

Worth noting is that cargo and npm weren't "settled around"; they were developed and presented, from the beginning, alongside the relevant compiler and runtime. There was never a question; the batteries were included. Leiningen is the weird one where people did actually settle fairly well around an unofficial solution in the absence of an official one. I think the norm with languages that forego official tooling is c…

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.
Post reply on HN