Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python Practical Package Packing 2024

matt.sh

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Python Practical Package Packing 2024

#11

Post by lbhdc »

jolux wrote: post #8
chad1n wrote: post #6

Poetry is so slow, please use uv, for some of my projects, poetry takes 20-30 seconds to update/add new packages while uv completes it in seconds. But I can agree that's better to use a package manager than plain old `requirements.txt` file since you can pin the version you want to use for development or production.

Does uv support platform independent lockfiles now?

Yeah the `--universal` flag should do that.

  uv pip compile --universal requirements.in -o requirements.txt

Re: Python Practical Package Packing 2024

#12

Post by PaulHoule »

aweektogetit wrote: post #7
PaulHoule wrote: post #3

Earlier quoted context omitted.

uv rules and poetry drools; I like the idea of poetry but once you see how fast uv can build your environment whether or not the files are in cache I think you could never go back to poetry.

Is the UX comperable? Might try this

uv feels a lot like pip but unlike pip it has a correct resolution algorithm. I understand that people are working on a higher-level product that incorporates uv.

Re: Python Practical Package Packing 2024

#13

Post by akoumjian »

I've been liking pdm as opposed to poetry, as poetry uses some non-standard syntax in the pyproject.toml file. I had a lot of trouble getting hatch environments to handle changes to default python versions and the like. I like how pdm played nicely out of the box with pyenv if you're using it, otherwise manages environments directly.

Re: Python Practical Package Packing 2024

#16

Post by whywhywhywhy »

Just feel this needs to be solved higher up the pipeline than where they're trying to solve it. The fact multiple versions of the same library can't coexist in a project meaning you end up having to find this plateaux where every dependency is within range if they cross over. Node/NPM can do this, don't really see why Python couldn't eventually and read dependencies from within the project folder rather than this whole fake idea that it exists at a system level which just hasn't been the reality of how people are using this language for a long time.

Re: Python Practical Package Packing 2024

#17

Post by pqdbr »

For someone that is from the Ruby world and uses rbenv / bundler confortably, what would be the canonical way of using / managing Python in MacOS?

There seems to be a sea of alternatives and I see every tutorial mention `pip install` while I don't even have that running in my CLI (only pip3). Do people assume an alias here of I have somehow messed up my environment?

Re: Python Practical Package Packing 2024

#18

Post by Arch-TK »

Matt needs to stop this "I know better than you" attitude.

Seriously, first C and now Python.

I can't wait for the 20th revised version of this blog post where Matt has slowly realises he doesn't know half as much as he claims to and has added 50 side notes explaining all the cases where his blanket statement is not quite as broadly applicable as he ignorantly assumed.

Re: Python Practical Package Packing 2024

#19

Post by frognumber »

lbhdc wrote: post #5

While the author enumerates the things they think you should do, I think it was very light on the _why_ you would want this setup. I think the argument of "you are doing it the old way" have been really ineffective at convincing people to do anything different, particularly around python tooling. The official docs recommend doing many of the things the author cautions against or calls bad. https://packaging.python.or…

As you scroll down, it gets worse.

"Bonus: Legacy Outdated Python Usage Warning Signs" was a helpful list of things to look at, but I disagree with many as best practices. I like when code from the year 2000 still works, and you do that by using standard packages.

The chase for the latest / greatest means bitrot and is the sign of a junior developer. You save a bit of time in the short term, but a new latest / greatest comes out a few years later.

The conclusion is a bit weird too. That kind of rant is what leads to no-hire decisions. Be careful what you put online.

Re: Python Practical Package Packing 2024

#20

Post by d_burfoot »

I think it's fine to have high-concept dependency management for the Serious Python Professionals, but what about for people who just want to put a project together and not have their life taken over by figuring out YAML syntax, new-hotness build tools, and dependency graph structures?
Post reply on HN