What the Heck Is Pyproject.toml? • Hacker News Board

Re: What the Heck Is Pyproject.toml?

#171

Post by ProZsolt » Thu, Apr 02, 2020, 5:31 PM UTC

BiteCode_dev wrote: post #142

codeduck wrote: post #122

Earlier quoted context omitted.

> Python is otherwise the most incredible language of our times This is a strong claim. Ruby could arguably make the same claim. So could Elixir.

Given none of them are used outside of their specialty, no. For Python, it's the reversed: it's used everywhere, except for a few topics. It's the only scripting language like that.

People have this bias that Ruby only used with Rails. Yes, Rails made it popular in the first place, but it has overgrown it. Other than data science/machine learning (because of the lack of libraries/frameworks) Ruby used in all over the place, just like Python. Ruby basically ruled the DevOps space before Go and still very relevant.

Yes, Python is winning the popularity battle no doubt on that, but that nothing to do to the language or the surrounding tooling itself. It's like saying VHS is an incredible format compare to Betamax(Yes I'm old :D).

I used Ruby (not Rails) and Python for many years by now. I think Ruby and its tooling are far better than Python's. But if anybody asked me which language should they learn as their first, it would be Python, just because there will be more jobs available.

Re: What the Heck Is Pyproject.toml?

#172

Post by earthboundkid » Thu, Apr 02, 2020, 5:36 PM UTC

j0057 wrote: post #166

earthboundkid wrote: post #156

Earlier quoted context omitted.

> The hidden (not deleted) comments are hidden not because they contain criticism, but because of an unnecessarily harsh tone, which is unhelpful to anyone wanting to read up on the discussion at hand, and definitely not helpful for the motivation of anybody currently doing the unthankful work of maintaining pip. I reread the thread last night and asked, Was I too harsh? Am I discouraging the thankless pip team? Obvi…

Well, at your use of the term 'gaslighting' I kind of like to quietly step out of saying, OK, whatever, this discussion has become especially unproductive.

If you know of another term for "someone else making you think the real problem is with you when in fact you're making a perfectly reasonable request" I'd be happy to use it to avoid triggering snowflake cons.

Re: What the Heck Is Pyproject.toml?

#173

Post by twic » Thu, Apr 02, 2020, 6:02 PM UTC

brettcannon wrote: post #170

nicoburns wrote: post #141

Earlier quoted context omitted.

NPM has excellent support for compiled extensions, despite being mostly used for web development.

I think something people are forgetting when comparing Python's packaging system to other languages and runtimes is how old Python and its ecosystem is. For instance, Python's public release predates Linux's public release(Feb 1991 versus Aug 1991). The first release of setuptools was 2004 and it isn't like people weren't sharing Python code even before then ( https://github.com/pypa/setuptools/commit/8423e1ed14ac169…

The age also means Python has had plenty of time to come up with something new!

Re: What the Heck Is Pyproject.toml?

#174

Post by jakearmitage » Thu, Apr 02, 2020, 6:55 PM UTC

fermienrico wrote: post #4

Python desperately needs a better packaging solution than pip from Python Software Foundation. Stop all new features until this - the biggest pain point for Python across all expertise levels from newbies to experienced Python programmers - is officially solved. No pipenv, no poetry, no conda, etc from third party devs who sometimes get tired of the pressure [1]. It is immense. Combine all this virtualenv stuff with…

Wonderful language, crippling ecosystem.

Re: What the Heck Is Pyproject.toml?

#175

Post by BerislavLopac » Thu, Apr 02, 2020, 7:11 PM UTC

twic wrote: post #173

brettcannon wrote: post #170

Earlier quoted context omitted.

I think something people are forgetting when comparing Python's packaging system to other languages and runtimes is how old Python and its ecosystem is. For instance, Python's public release predates Linux's public release(Feb 1991 versus Aug 1991). The first release of setuptools was 2004 and it isn't like people weren't sharing Python code even before then ( https://github.com/pypa/setuptools/commit/8423e1ed14ac169…

The age also means Python has had plenty of time to come up with something new!

And it (and by "it" I mean the Python community) absolutely did! The main problem that it has come up with numerous different somethings that have been competing to become standards, across a wide range of related, but separate areas (packaging, versioning, environments...), and only a few of them (like pip) managed to become partial (but not at all universal) de facto standards.

Re: What the Heck Is Pyproject.toml?

#176

Post by jshen » Thu, Apr 02, 2020, 8:05 PM UTC

j88439h84 wrote: post #86

jshen wrote: post #82

Earlier quoted context omitted.

This is worse than how it’s done on most modern languages.

That's why we use Poetry.

yeah, that's what i tried to use for a while too. The problem is that so much of the ecosystem doesn't use it, and the python community fails to converge on a solution here the way other language communities do.

Re: What the Heck Is Pyproject.toml?

#177

Post by jshen » Thu, Apr 02, 2020, 8:31 PM UTC

chc wrote: post #169

jshen wrote: post #45

Earlier quoted context omitted.

How do other people replicate your venv? How does production replicate your venv?

Sorry, I was a little terse — obviously you're right that you're not going to ship the virtualenv itself. As other people have said, the intent was that you create a requirements file (and/or maybe a setup.py if you need that functionality). What I meant is that between fiddliness and sluggishness of Poetry, and the marginal hassle of maintaining a requirements file and creating your own virtualenvs, I'm not sure Poe…

Thanks. My main point is that bundler, maven (less so), and npm are all better than either venv/pip/reqruirements.txt or poetry. Additionally, it's also better that those language communities have mostly converged on those solutions.

Re: What the Heck Is Pyproject.toml?

#178

Post by jshen » Thu, Apr 02, 2020, 8:33 PM UTC

toyg wrote: post #165

jshen wrote: post #83

Earlier quoted context omitted.

Node does it better as well. So does java with maven which has been the dominant way to do it in java for over a decade.

Maven is “so good” that people wrote another tool on top (Gradle) so they don’t have to touch the Mavenstrosity. More or less like Maven was built to get rid of that other nightmare, Ant.

Maven isn't as good as bundler or npm for sure, but it's better than the mess that is the python communities solution.

Re: What the Heck Is Pyproject.toml?

#179

Post by jshen » Thu, Apr 02, 2020, 8:47 PM UTC

zo1 wrote: post #149

mjfisher wrote: post #91

Earlier quoted context omitted.

I think you can certainly use Node as an example of much better developer experience. Even the difference between npm and yarn is fairly minimal, and there is a solid community 'default' in Yarn. I think part of the reason we ended up with so many trivial libraries and dependencies in the Node ecosystem was precisely because it is so easy to create and publish packages. I love Python as a language, but working with t…

No it's not... 99.9% of the time, installing dependencies is a breeze. Packaging is where the issue lies, but pulling those dependencies down is painless. You run one command and everything works. Unlike say npm/node/yarn where 50% of the time after coming back to work on a project your node_modules is broken and you have to either reinstall npm or node or node + npm.

The problem we're talking about isn't "installing a dependency", the problem is creating reproducible builds across people and between dev and production. The secondary problem is managing dependencies over the long run (updating, transitive dependencies, etc). Ruby/Bundler does this so much better than requirements.txt by a long shot.

Re: What the Heck Is Pyproject.toml?

#180

Post by jshen » Thu, Apr 02, 2020, 8:57 PM UTC

viraptor wrote: post #119

jshen wrote: post #82

Earlier quoted context omitted.

This is worse than how it’s done on most modern languages.

Different commands, but it's pretty much the same in similar languages: Ruby uses bundler configuration instead of virtualenv and gemfiles lock instead of requirements.txt. JS uses npm/yarn and lockfie. Go uses go.mod and does a lot of assumptions instead of virtualenv. (these days, it was worse) Modern languages do pretty much the same, just have a nicer wrapper for it.

It's not "pretty much the same". Have a separation between Gemfile and Gemfile.lock is a huge improvement over just having requirements.txt. Having good, easy to use commands, that manages this stuff for your in a way that works well for the vast majority of use cases (i.e. bundler), is far better than the ill-defined, ad-hoc, mess that is requirements.txt management.