Hacker News new | ask | show | jobs
by aranke 1106 days ago
I gave a talk about this at the Packaging Summit during Pycon which was well received, so the team is definitely aware of the problem.

However, the sense I got was that it was going to be a lot of work to “fix Python packaging” which wasn't feasible with an all-volunteer group.

At work, we're migrating away from pip as a distribution mechanism for this reason; I don't expect to see meaningful improvements to the developer experience anytime soon.

This is especially true because pip today is roughly where npm was in 2015, so there's a lot of fundamental infrastructure work (including security) that still needs to happen. An example of this is that PyPI just got the ability to namespace packages.

2 comments

> An example of this is that PyPI just got the ability to namespace packages.

You're thinking of organizations, which are not namespaces: https://blog.pypi.org/posts/2023-04-23-introducing-pypi-orga...

Right, but to an average developer, organizations look and feel very much like namespaces.

LWN even used namespaces in the title of the article describing the feature, which doesn’t help the confusion: https://lwn.net/Articles/930509/

That article is about the packaging summit talk on introducing namespaces, not about organizations. In fact, when talking about organizations, it explicitly says:

> But support for namespaces is not part of the new feature.

> we're migrating away from pip as a distribution mechanism for this reason

Could you elaborate on what you’re using as a replacement?

Not the parent but pipenv is decent, poetry is even better:

- clear separation of dev and production dependencies - lock file with the current version of all dependencies for reproducible builds (this is slightly difference than the dependency specification) - no accidental global installs because you forgot to activate a virtual environment - (not sure if supported by pip) allows installing libraries directly from a git repo, which is very useful if you have internal libraries - easier updates

We distribute a CLI tool (dbt), so we’re migrating to distributing using the following mechanisms:

1. curl script that installs dbt for end users

2. zipped snapshots for dbt Cloud, the SaaS hosted version of dbt

Eventually we want to create Docker images from 2, but we’re not there yet.