Live data from Hacker News

PYX: The next step in Python packaging

astral.sh

351–360 of 479 posts

Re: PYX: The next step in Python packaging

#351
post #55

Is there a big enough commercial market for private Python package registries to support an entire company and its staff? Looks like they're hiring for $250k engineers, starting a $26k/year OSS fund, etc. Expenses seem a bit high if this is their first project unless they plan on being acquired?

Continuum has been doing something very similar with Anaconda, and they've been around for over a decade now.

From what I can tell they (had to?) ramp up their aggressiveness regarding getting paid though.

They had contacted a company I had worked for asking them to purchase a license, because apparently somewhere in the company some dev workflow had contacted the conda servers regularly. We never ended up tracing it down as it stopped some weeks before them contacting us, according to our network logs.

In general, you don't resort to such sales tactics unless there is good cause (significant usage, where you as unpaid vendor also have leverage) or you just end up burning potential future customers (as was the case here, as they chose a bad contact point inside the company).

Re: PYX: The next step in Python packaging

#353
post #334

Earlier quoted context omitted.

Well I started with pip because it's what I was told to use. But it was slow and had footguns. And then I started using virtualenv, but that only solved part of the problem. So I switched to conda, which sometimes worked but wrecked my shell profile and often leads to things mysteriously using the wrong version of a package. So someone told me to use pipenv, which was great until it was abandoned and picked up by som…

Coming from the php ecosystem this kind of package manager problems feels crazy. Maybe Python and js people should just use composer too.

JS packaging ecosystem is fairly mature compared to python. The install and deps issues way fewer.

Re: PYX: The next step in Python packaging

#354

Earlier quoted context omitted.

Anaconda was a good idea until it would break apt on Ubuntu and make my job that much harder. That became the reason _not_ to use Anaconda in my book. venv made these problems start to disappear, and now uv and Nix have closed the loop for me.

Why don't you use pixi, which has the best from these worlds?

I agree. Pixi solves all of that issues and is fully open source including the packages from conda-forge.

Too bad there is nowadays the confusion with anaconda (the distribution that requires a license) and the FOSS pieces of conda-forge. Explain that to your legacy IT or Procurement -.-

Re: PYX: The next step in Python packaging

#355

Just try using ux with Google Artifact Registry and AWS CodeArtifact. You need the username in the URL with GAR and you need it in the environment variable with AWS. I'm not sure who's causing the pain with using uv with private repositories (but I'd bet it's uv), but they are selling a solution to that pain. Full disclosure, uv rocks and is way better than poetry, setuptools and whatever complicated and non-zen way…

In my experience (albeit from about 4 years ago) having some kind of private package with pipenv (or even plain pip) was really annoying. We went the route of a private repo on Github rather than a private package repository, which maybe set us up for exactly that annoyance.

Re: PYX: The next step in Python packaging

#356
To be honest, this was just a matter of time. As a long time Python developer, I just can’t wrap my head around the lack of something like this. GitHub was going to get hosted packages for Python but never did because it “didn’t align with their strategy objectives and a reallocation of resources” [1] (or some other similar corpospeak) Astral is a great company and I think we can’t question what they’ve achieved and provided to the Python community. uv is a game changer and solves one of the core issues with Python by providing a unified tool that’s also fast, reliable and easy to use. In fact, after using uv for the first time (coming from a combination of pyenv + poetry) I never wanted to go back and this is something all of my peers have experienced too. I’m glad it’s Astral who is doing this, and of course they will have to make money one way or another (which is perfectly fine and I don’t think anyone on this forum can be against that, as long as they are actually providing real value) but I was honestly tired of the paralysis on this matter. I did try to build a registry (pyhub.net) but being just one person with almost no resources and having another full time business made it impossible. Anyway, congrats to the team for the effort! [1] https://github.com/orgs/community/discussions/8542

Re: PYX: The next step in Python packaging

#357
I personally use Nixpkgs to fully isolate python installation on per project basis. And inside this isolated env, once python is built, usually using pip is enough and works well

This way, !each of my repositories has its own nix file defining the list of dependencies and it can easily be built per system as well

Re: PYX: The next step in Python packaging

#359
post #55

Is there a big enough commercial market for private Python package registries to support an entire company and its staff? Looks like they're hiring for $250k engineers, starting a $26k/year OSS fund, etc. Expenses seem a bit high if this is their first project unless they plan on being acquired?

I would love to have something that replaces JFrog's Artifactory or Sonatype Nexus. Having _just_ a python registry IMO limits the enterprise audience by quite a bit (even if it is much better for Python-specific issues)

Re: PYX: The next step in Python packaging

#360

Earlier quoted context omitted.

Human naming has nothing to do with software naming which seems obvious but apparently not. Python package creators should check the pypi registry for names and generally avoid name collisions where reasonable. Common sense applies for reduced confusion for users globally and also for potential legal issues if any party trademarks their software name. What makes one pyx more real than the other is one was first and t…

> https://pypi.org/project/PyX/ the last release is Oct 16, 2022. are we doing this like jerseys - the name is now retired because pyx won all the championships?

That's barely 3 years...? I just released an update for a project I maintain that had had a 4 year gap between releases, but is still heavily used by a lot of people. I dread to think that we live in a world where software has arbitrary expiry dates...?

Some software just needs fewer updates. The actual repo had a few commits last year and even more the year before that.

Post reply on HN