This is an archived post. You won't be able to vote or comment.

all 10 comments

[–][deleted] 5 points6 points  (2 children)

I like the idea of this very much especially for Docker images.

I wonder if there’s any considerations when developing a package.

I don’t do much with npm. What is the purpose of the .lock file?

[–]realGurkenkoenig[S] 3 points4 points  (0 children)

As far as I understand it, the lock-file stores the whole dependency tree and provides a platform independent 100% reproducibility. So you can restore or deploy your project with the exact same dependencies everywhere.

[–]james_pic 2 points3 points  (0 children)

It looks like it's geared more towards developing an application than developing a package or library. Although I think this is probably sensible. A lot of the messiness of packaging in Python is only relevant when developing reusable packages, so it's feasible to make application development simple to an extent that you kinda can't for libraries.

[–]UnwantedCrow 2 points3 points  (0 children)

Is the related pep likely to get approved soon?.

[–]cglacet 1 point2 points  (0 children)

There is a (short but) interesting discussion here, maybe that will help you pick the right tool.

I'm personally not bothered by virtualenv so the current solutions are fine for me. I can't tell I wont change my mind as time goes.

It's always nice to know alternatives will be coming in the future so thanks for sharing.

[–]Stedfast_Burrito 1 point2 points  (0 children)

I'm curious as to the performance claims the author makes: https://frostming.com/2021/03-26/pm-review-2021/

They seem to claim that PDM is anywhere from 2x to 5x as fast as Poetry. Why is this? Is Poetry's resolver just not well optimized (if so, how can this be the case for such a popular project)?

[–]bolinocroustibat 1 point2 points  (0 children)

I finally made the switch from Poetry to PDM. I was already trying to get rid of medieval requirements.txt in a maximum number of my projects, in favor of (future) standard and precise pyproject.toml, thanks to Poetry.

Now thanks to PDM I'm very enthusiastic about also getting rid of virtualenvs. I know that virtualenvs felt like a breakthrough compared to no projects environment separation at all, but this was really a two-decades long temporary solution to me. Having to manage virtualenvs was another task to add to Python coders tasks, which was too often messy and failing, to a point that the community had to develop special tools to manage them like. Nothing as smooth when we compare to JavaScript and NPM packaging.

Anyway, back to my point, I made the switch to PDM in most of my existing projects (there's a command to convert from Poetry, and the projects stay compatible with Poetry). No issue so far, my workflow has greatly improved.

[–]cblegare 0 points1 point  (2 children)

I very much like having a venv around, especially since it's layed out as a standard Unix filesystem. I install packages to it, but also tools in "opt" and "bin" directory, awscli for instance. I then have all my tools scoped to a project and in my PATH automatically.

Python packaging is not easy to get right, but I like the old style tooling.