[HN Gopher] PDM: A Modern Python Package Manager
___________________________________________________________________
PDM: A Modern Python Package Manager
Author : sciurus
Score : 43 points
Date : 2021-12-09 20:47 UTC (2 hours ago)
(HTM) web link (pdm.fming.dev)
(TXT) w3m dump (pdm.fming.dev)
| roomey wrote:
| Is virtualenv not very useful? I use pipenv and find it extremely
| useful having my various projects separate.
|
| Also when deploying to kubernetes or whatever it works the same
| way
| majormunky wrote:
| So this is sort of like a virtualenv, except you don't need to
| activate anything, it just looks within the main project folder
| for a __pypackages__ folder, and uses that to look for packages
| qbasic_forever wrote:
| You kind of answered your own question. Virtualenv alone is too
| much work so you're using a tool like pipenv to streamline it.
| This is a similar idea to have less ritual and a faster
| developer workflow.
| johnhowardstein wrote:
| It's a single command more, and then you don't need to prefix
| everything with pipenv run.
| bruiseralmighty wrote:
| I use only virtualenv and have never really had any issues with
| it for separating out my project environments.
|
| Perhaps this is more of an issue with larger projects, but I
| also noticed that 'no need to use virtualenv' as a positive.
| akdor1154 wrote:
| Cool to see an implementation of __pypackages__ support.
|
| Ill still use Poetry, but this could be paving the way for Poetry
| to work without virtualenvs as well one day.
| kaesar14 wrote:
| Another package manager for Python is exactly what the world
| needed
| smegsicle wrote:
| over and over until one doesn't suck
| [deleted]
| gigatexal wrote:
| Looks a lot like poetry
| divbzero wrote:
| PDM's support of PEP 582 seems promising. What would be even
| cooler is if the maintainers of pip agree with PEP 582 and
| incorporate it into pip itself.
| fb03 wrote:
| Genuine question: If I am starting a Python project NOW, which
| one do I use? I have been using pipenv for quite some time and it
| works great but locking speed has been problematic, specially
| after your project grows large enough (minutes waiting for it to
| lock without any progress warning at all).
|
| Should I just upgrade to Poetry or should I just dive headfirst
| into PDM? Keep myself at Pipenv? I'm at a loss.
|
| Thanks in advance!
| odiroot wrote:
| Just go for virtualenv and pip. Virtualenvwrapper to have handy
| shell tools.
| Nextgrid wrote:
| Alternatively, pyenv and pyenv-virtualenv for shell
| integration and seamless virtualenv activation.
| timothylaurent wrote:
| This is our setup - fits perfectly, don't even miss
| `workon`
| stavros wrote:
| Use Poetry. It does everything you need and PDM is a bit too
| new still.
| fb03 wrote:
| Great. I have heard "anecdata evidence" that sometimes poetry
| fails to install a combination of packages or something along
| those lines, did you find any of those shenanigans in your
| own experience?
| akdor1154 wrote:
| (Not GP) Occasionally, but still use poetry.
|
| The issues happen because poetry is strict about version
| constraints. Pip used to be lax, so some packages could get
| away with poor/overly restrictive constraints..
|
| Now pip is strict as well, and poetry is also getting a lot
| more common, so maintainers have had pressure to fix most
| of these issues.
| nbadg wrote:
| I've run into this a couple of times. Typically it's when
| starting a new project and gradually adding dependencies.
| By default, when adding (poetry add <dep>), poetry adds the
| most recent version of the library, and in pyproject.toml
| that becomes the minimum possible version. If you then
| later try to add something that depends on that library,
| but isn't up-to-date on the most recent version, poetry
| will (correctly!) error out because it fails to find a
| compatible solution. For example, something like this:
| poetry add ingredients # most recent version: 1.0
| poetry add cake # requires ingredients, but <1.0
|
| So here, poetry would add ingredients to your
| pyproject.toml with version = "^1.0.0" in the first step.
| In the second step, when you tried to add cake as a new
| dependency, it would say it can't find a version of cake
| compatible with your pyproject.toml's requirement for
| ingredients.
|
| The solution is to change pyproject.toml to be more
| permissive about the version of ingredients, resulting in
| it downgrading to a compatible version. Or submit an issue
| and/or PR with the maintainers of cake to bump up the
| supported versions.
| acidbaseextract wrote:
| No shenanigans for any library-ish code with few
| dependencies that targets relatively modern Python.
|
| I've had one or two fundamental version conflicts with a 5+
| year old application with 100+ dependencies and a decent
| amount of legacy stuff. They were a pain in the ass, and
| the sdispater's stance on not allowing overrides is a pain
| in the ass. We ended up forking the upstream libraries to
| resolve the version conflict.
|
| With all of that, poetry is amazing and a huge step
| forward. I'd advocate it wholeheartedly.
| cwp wrote:
| I just started a Python project, using PDM. So far, I like it a
| lot. If I hit a show-stopper, no big deal, it's pretty easy to
| switch.
| zuj wrote:
| Oh, no. Please, not one more.
| rossipedia wrote:
| How many times must we teach you this lesson, old man?
|
| https://xkcd.com/927/
| carabiner wrote:
| So many of these... I now need a tool to manage the managers.
| Kinrany wrote:
| How does it compare to poetry?
| jefurii wrote:
| We keep having to repost this: https://xkcd.com/1987/ Why don't
| we ever learn?
| pyuser583 wrote:
| Another one?
| sterwill wrote:
| There should be a rule that before you create a new Python
| package manager, you have to kill off an existing one first.
| [deleted]
| denysvitali wrote:
| Thanks! I was really missing yet another package manager
| cosmotic wrote:
| Please use descriptive words instead of 'modern'. Modern, to me,
| in this context, means untested and unreliable.
| cozzyd wrote:
| I can't wait for the postmodern package managers...
| cdot2 wrote:
| packages are really a social construct
| dangerbird2 wrote:
| Inspired by Michel Foucault's _Pypi and Punish_
| tamentis wrote:
| You `pdm install requests` and it installs Django.
| tamentis wrote:
| "The Python Package Manager That Is Newer Than All The Others"
| diogenesjunior wrote:
| >Modern, to me, in this context, means untested and unreliable.
|
| that's what PDM is
| [deleted]
| mindwok wrote:
| I tried PDM earlier this year and there's a few things worth
| noting:
|
| - PEP582 which it is based on is still in draft, and some tools
| (VS Code) won't fully support it until it's accepted.
|
| - If you want to develop or test using different Python versions,
| you still need to use a virtual environment. PDM does handle this
| for you though.
|
| IMO, the Python packaging ecosystem has been a dumpster fire for
| a long time, but the flurry of recent PEPs that provide a
| standard way of defining a package with pyproject.toml have made
| it so much better. Now it's just a matter of the tools catching
| up.
| tapia wrote:
| So, what's the difference with poetry? It seems pretty similar to
| me. Do we really need another python package manager?
| lelandbatey wrote:
| The big distinguisher of PDM is that it support PEP 582[0].
| That means it works less like Pip and works more like NPM of
| the JS world. To quote PEP 582:
|
| > This PEP proposes to add to Python a mechanism to
| automatically recognize a __pypackages__ directory and prefer
| importing packages installed in this location over user or
| global site-packages. This will avoid the steps to create,
| activate or deactivate "virtual environments". Python will use
| the __pypackages__ from the base directory of the script when
| present.
|
| Thus, the idea of PDM is that it will create a directory,
| called `__pypackages__` in the root of your project and in that
| folder it'll populate all the dependencies for that project.
| Then, when you run scripts in the root folder of your project,
| your Python install will see that there's a `__pypackages__`
| folder and use that folder to look up dependencies.
|
| This style of "dependencies inside the project directory" is
| similar to how npm of the Javascript ecosystem works, where it
| creates a `node_modules/` folder in the root of your project
| and fills that folder with the dependencies for your project.
| This style of dependency management is different from other
| package managers such as Poetry (Python), Pip (Python), go
| (Golang), and cargo (Rust), all of which instead have a sort of
| "secret folder acting as cache of dependencies at particular
| versions", a folder that's usually pretty hidden out of the
| way, in which the package manager automatically manages the
| acquisition, storage, and versioning/version resolution
| (Poetry, Go, Cargo, all do this but Pip does not).
|
| That's a very fast and probably wrong rundown on what makes
| this package manager different from others.
|
| [0] - https://www.python.org/dev/peps/pep-0582/
| divbzero wrote:
| I've long been of the opinion that pip and venv (and
| sometimes pyenv) is good enough. PEP 582 is a rare instance
| where a new packaging proposal makes sense right away when I
| read it and could beat pip and venv in simplicity.
|
| It seems functionally similar to venv but has the benefit of
| standardizing the location of dependencies to ___pypackages__
| /3.x/*_. With venv the developer selects some arbitrarily
| named directory that is sometimes but not always _.venv /*_.
| tomrod wrote:
| Wow! This is basically dramatically simplifying to a "venv
| per script" type approach -- some basic file reorganization
| and you're solid.
|
| I have not come across PEP 582, thank you for linking.
| twunde wrote:
| Basically PDM supports project-specific python package
| installs. This is different from how python has traditionally
| worked where it has installed globally for the user running
| it. Why is this important? Because with virtual environments
| it's easy to forget to activate a virtual environment and run
| a pip install or upgrade and clobber your computer or
| server's python environment. It also avoids the confusing
| issue where someone updates their PATH variable while in a
| venv, but then its no longer there after exiting the virtual
| environment.
| jrimbault wrote:
| Composer (php) also uses the "project local" approach
___________________________________________________________________
(page generated 2021-12-09 23:00 UTC)