Live data from Hacker News

How to make a Python package in 2021

antonz.org

31–40 of 215 posts

Re: How to make a Python package in 2021

#31

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…

To be fair, while this is a single article, if you only look at step 1, 2 and 3, you get a fully published package with only one tool used (flit) and not much extra. It's the succeeding sections (A, B, C, D, E) that get more advanced, but they're all optional. You should definitely do A, but the rest I'd say it's a lot more opinionated and definitely not needed.

Fair point. I wouldn't recommend this article to someone just starting out with python, though. It's often good to understand generation n-1's way of doing things but not too be married to it.

Re: How to make a Python package in 2021

#32

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.

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.

I completely agree. Elsewhere we see sanity by default, in Python there's still open questions and hopeful but early stage projects.

Re: How to make a Python package in 2021

#33
post #21

Earlier quoted context omitted.

> You don't need to solve all those problems at once. Why spend time tweaking the setup when you can just get it right in the first place with less work?

Do you recommend poetry? I've been meaning to try it but haven't had the time to migrate an existing project to poetry.

Yeah it's pretty good. There are plenty of problems and holes of course, but for most pure-Python packages it does a nice job most of the time.

If you're an expert, you can do it with setup.py or setup.cfg, but I don't think it's normally worth the trouble.

Re: How to make a Python package in 2021

#34

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…

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.

One thing that has become clear to me, from playing around a bit with go, rust, and nim, is that it is astonishingly better when the language has exactly one set of tools, that everyone uses.

Even if that set of tools is kinda crappy (Glances at go), it's just so nice to not have all the bikeshedding and just get on with it.

Re: How to make a Python package in 2021

#37

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.

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.

The issue is that every time the community settles on a tool a new tool is made to fix the issues with the old tool rather than just refactoring the old tool.

Re: How to make a Python package in 2021

#39
post #25

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.

It's fragmented, but it doesn't need to be error prone if people use the good tools instead of the old low-level tools.

There would be no room for error if we just put the libraries in with the project as files instead of adding all these extra steps. Nobody seems to like this simple, bulletproof method anymore for some reason though.

Re: How to make a Python package in 2021

#40
post #3

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

+1 for poetry. It also includes deterministic dependency resolution with a lock file. I just published a repo today[0] using Poetry and it didn’t take me more than 5 minutes. Poetry build && poetry publish [0] https://github.com/santiagobasulto/hyper-inspector

This looks cool. I had never come across rich[0] before.

[0] https://github.com/willmcgugan/rich

Post reply on HN