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

PYX: The next step in Python packaging

astral.sh

Post reply on HN
Print view View original

301–310 of 479 posts

Re: PYX: The next step in Python packaging

#301

Post by nicce »

almostgotcaught wrote: post #258
iepathos wrote: post #243

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?

Believe or not, some software can be ”complete”.

Re: PYX: The next step in Python packaging

#302

Post by rcleveng »

aledalgrande wrote: post #267
bastawhiz wrote: post #204

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…

Man I used python sparingly over the years and I still had to deal with all those package manager changes. Worse than the JS bundling almost?

No, the JS bundling changes are almost monthly and it's impossible to know which one should I use and what will be broken because of my choice.

Re: PYX: The next step in Python packaging

#303

Post by rcleveng »

integralid wrote: post #280
bastawhiz wrote: post #204

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…

What's wrong with just using virtualenv. I never used anything else, and I never felt the need to. Maybe it's not as shipping l shiny as the other tools, but it just works.

The problem is you can do whatever you want in it, and then have no way of reproducing that.

pyproject.toml tries to fix it, poetry kept wanting to use their own wonky names for the tags, I'm not sure why.

Once that is standardized, venvs should be cattle and not pets. That is all that is needed. UV makes that fast by hardlinking in the libraries and telling you the obvoius (that venvs should be cattle and not pets)

This fight was poetry's to loose.

Re: PYX: The next step in Python packaging

#304

Post by [deleted] »

integralid wrote: post #280
bastawhiz wrote: post #204

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…

What's wrong with just using virtualenv. I never used anything else, and I never felt the need to. Maybe it's not as shipping l shiny as the other tools, but it just works.

[deleted]

Re: PYX: The next step in Python packaging

#305

Post by rcleveng »

rs186 wrote: post #252
bastawhiz wrote: post #214

Earlier quoted context omitted.

I'd otherwise agree but this problem seems unique to Python. I don't have problems like this with npm or composer or rubygems. Or at least very infrequently. It's almost every time I need to update dependencies or install on a new machine that the Python ecosystem decides I'm not worthy.

I think pip made some poor design choices very early, but pip stuck around for a long time and people kept using it. Of course things got out of control, then people kept inventing new package management until uv comes along. I don't know enough about Python to understand how people could live with that for so long.

like what?

Re: PYX: The next step in Python packaging

#306

Post by _the_inflator »

computershit wrote: post #198
runningmike wrote: post #103

All python packaging challenges are solved. Lesson learned is that there is not a single solution for all problems. getting more strings attached with VC funded companies and leaning on their infrastructure is a high risk for any FOSS community.

> All python packaging challenges are solved. This comes across as uninformed at best and ignorant at worst. Python still doesn't have a reliable way to handle native dependencies across different platforms. pip and setuptools cannot be the end all be all of this packaging ecosystem nor should they be.

„across different platforms“

First things first:

Import path, os

I love Python, the ZEN of it, and you really need to accept the fact that there are conventions - quite a lot and that bash or shell scripts are where the magic happens, like environmental variables, if you know how to secure your app.

Even the self thing finally makes sense after years of bewilderment (“Wait: not even Java is that brutal to its users.”)

Lately stumbled over poetry after really getting the gist out of venv and pip.

Still hesitant, because Windows doesn’t play a role.

Re: PYX: The next step in Python packaging

#307

Post by divbzero »

integralid wrote: post #280
bastawhiz wrote: post #204

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…

What's wrong with just using virtualenv. I never used anything else, and I never felt the need to. Maybe it's not as shipping l shiny as the other tools, but it just works.

There’s nothing wrong with just using virtualenv. I too have used virtualenv plus pip (and sometimes pyenv) for the longest time without issue.

However, uv is the first alternative that has tempted me to switch. uv offers performance improvements over pip and handles pyenv use cases as well. I’ll be paying attention to pyx to see how it pans out.

Re: PYX: The next step in Python packaging

#309

Post by jillesvangurp »

dakiol wrote: post #39

I'm brushing up with Python for a new job, and boy what a ride. Not because of the language itself but the tooling around packages. I'm coming from Go and TS/JS and while these two ecosystems have their own pros and cons, at least they are more or less straightforward to get onboarded (there are 1 or 2 tools you need to know about). In Python there are dozens of tools/concepts related to packaging: pip, easy_install,…

> Why is that hard for the Python community to come up with a single tool to rule them all?

Design by committee is hard. Especially building consensus around reconsidering what at this point should be considered bad design. Python has a few decades of that. It took decades for the to even consider starting the process of removing the GIL, which is a great example of "it's clearly broken but lets not fix it". Packaging is the same.

These guys are laser focused on just fixing things the right way and that's what it takes,

There seems to be a lot of movement around some of these topics. The Gil is being removed, python's performance issues are meling away with recent releases, and things like uv are happening. I like it.

Re: PYX: The next step in Python packaging

#310

Post by wtallis »

BrenBarn wrote: post #248
woodruffw wrote: post #157

Earlier quoted context omitted.

Snark aside, you're missing the part where pyx doesn't compete with PyPI. It's a private service.

How does it being private mean it doesn't compete with PyPI?

Its purpose is to serve as a repo for stuff that was never going to go on PyPI, whether or not PYX exists.
Post reply on HN