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

141–150 of 479 posts

Re: PYX: The next step in Python packaging

#141

Post by tomwphillips »

LtWorf wrote: post #116
tomwphillips wrote: post #101

>Modern I'll pass. I'd rather have the battle-tested old thing, thanks.

I've been limiting myself to whatever is available on debian and it's been fine for me since several years. I don't understand why people who don't do weird AI stuff would use any of that instead of sticking to distribution packages and having the occasional 1 or 2 external modules that aren't packaged.

Indeed, to expand on my remark: I wrote Python in academia for ~6 years and then professionally for nearly a decade in data science, data engineering and backend web apps. Virtualenv was fine. Pipenv had a nicer CLI and easier to use dependency pinning. But fundamentally all this stuff worked fine.

Re: PYX: The next step in Python packaging

#142

Post by zahlman »

LtWorf wrote: post #116
tomwphillips wrote: post #101

>Modern I'll pass. I'd rather have the battle-tested old thing, thanks.

I've been limiting myself to whatever is available on debian and it's been fine for me since several years. I don't understand why people who don't do weird AI stuff would use any of that instead of sticking to distribution packages and having the occasional 1 or 2 external modules that aren't packaged.

Because making external modules cooperate with the system environment is awkward at best (and explicitly safeguarded against since 3.11, since it can cause serious problems otherwise even with "user" installs), and installing the distro's packages in a separate environment is not supported as far as I can tell. And because the system environment is often deliberately crippled; it may not even include the entire standard library.

Re: PYX: The next step in Python packaging

#143

Post by awesome_dude »

thedanbob wrote: post #112
chao- wrote: post #106

Earlier quoted context omitted.

I'm surprised to hear that. Ruby was the first language in my life/career where I felt good about the dependency management and packaging solution. Even when I was a novice, I don't remember running into any problems that weren't obviously my fault (for example, installing the Ruby library for PostgreSQL before I had installed the Postgres libraries on the OS). Meanwhile, I didn't feel like Python had reached the bar…

Bundler has always been the best package manager of any language that I've used, but dealing with gem extensions can still be a pain. I've had lots of fun bugs where an extension worked in dev but not prod because of differences in library versions. I ended up creating a docker image for development that matched our production environment and that pretty much solved those problems.

> I ended up creating a docker image for development that matched our production environment and that pretty much solved those problems.

docker has massively improved things - but it still has edge cases (you have to be really pushing it hard to find them though)

Re: PYX: The next step in Python packaging

#144

Post by Thrymr »

notatallshaw wrote: post #46
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,…

> easy_install I don't know what guides you're reading but I haven't touched easy_install in at least a decade. It's successor, pip, had effectively replaced all use cases for it by around 2010.

> I don't know what guides you're reading but I haven't touched easy_install in at least a decade.

It is mentioned in the "Explanations and Discussions" section [0] of the linked Python Packaging guide.

Old indeed, but can still be found at the top level of the current docs.

[0] https://packaging.python.org/en/latest/#explanations-and-dis...

Re: PYX: The next step in Python packaging

#146

Post by xavdid »

woodruffw wrote: post #33
cpeterso wrote: post #27

How do you pronounce "pyx"? Pikes, picks, pie-ex?

We've been pronouncing it pea-why-ecks, like uv (you-vee) and ty (tee-why). But I wouldn't say that's permanent yet.

that's fascinating - I've definitely been saying "you've" and "tie". I assumed this was "picks"

Re: PYX: The next step in Python packaging

#147

Post by neutronicus »

HiPhish wrote: post #88
Muromec wrote: post #44

Earlier quoted context omitted.

The word "left" is now very charged too, maybe even more than "viral".

Every word is charged now, so you might as well use it. "Copyleft" is a fine pun on "copyright".

Careful, or you'll get the copyleftists calling you a neo-libre-al.

Re: PYX: The next step in Python packaging

#150

Post by dimatura »

rob wrote: 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?

Just one data point, but if it's as nice to use as their open source tools and not outrageously expensive, I'd be a customer. Current offerings for private python package registries are kind of meh. Always wondered why github doesn't offer this.
Post reply on HN