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

What the Heck Is Pyproject.toml?

snarky.ca

Post reply on HN
Print view View original

181–190 of 199 posts

Re: What the Heck Is Pyproject.toml?

#181

Post by viraptor »

jshen wrote: post #180
viraptor wrote: post #119

Earlier quoted context omitted.

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.

Gemfile-gemfile.lock is setup.py-requirements.txt.

And yes, as I said, a nice wrapper for management of it is missing in python. The main ideas/approach is the same though.

Re: What the Heck Is Pyproject.toml?

#182

Post by jshen »

viraptor wrote: post #181
jshen wrote: post #180

Earlier quoted context omitted.

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.

Gemfile-gemfile.lock is setup.py-requirements.txt. And yes, as I said, a nice wrapper for management of it is missing in python. The main ideas/approach is the same though.

It’s really not the same. Gemfile lists the direct dependencies of your project with variable specificity of explicit versions. Gemfile.lock lists all dependencies after resolving your direct dependencies and locks them to specific versions. requirements.txt is some bastardization of both of these combined, and setup.py is neither of these it’s for distribution of modules/packages which Ruby has as well, but it’s not your gemfile.

edit: also, how do you manage dev dependencies with requirements.txt and setup.py?

Re: What the Heck Is Pyproject.toml?

#183

Post by viraptor »

jshen wrote: post #182
viraptor wrote: post #181

Earlier quoted context omitted.

Gemfile-gemfile.lock is setup.py-requirements.txt. And yes, as I said, a nice wrapper for management of it is missing in python. The main ideas/approach is the same though.

It’s really not the same. Gemfile lists the direct dependencies of your project with variable specificity of explicit versions. Gemfile.lock lists all dependencies after resolving your direct dependencies and locks them to specific versions. requirements.txt is some bastardization of both of these combined, and setup.py is neither of these it’s for distribution of modules/packages which Ruby has as well, but it’s not…

You can put dev deps in extras in their own "dev" block. Similar to how gemfile uses groups. Use requirements-dev.txt for them. Requirements for is a full list of dependencies after resolution and their exact versions. (as produced by freeze) The main difference is that requirements is "as installed in current configuration", while gemfile.lock is "for any groups configuration".

Again, not as polished experience, but the model matches.

Re: What the Heck Is Pyproject.toml?

#184

Post by brettcannon »

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!

I'm not sure how old you are, but if you don't know the name "Borland" you might not realize how novel it is to have a compiler on every major OS. While Python's age means it has been around to see a lot of changes occur, that also means it had pre-existing practices and code to also consider whenever a shift in the industry occurred. Plus in hindsight things look obvious, but during the transition it isn't obvious what will stick and what won't.

It's pretty remarkable that things have continued to function since my 17 years with Python alone have seen things like:

- Compilers becoming available on all OSs - Linux becoming a thing - Laptops becoming common - Smartphones - Web-based email clients

As I have said a few times in comments on this thread, it's fine to feel like there's room for improvement, but trying to "stick it" to Python and its packaging ecosystem in some way for not being perfect is pointless for you and demotivating for those who are actually in a position to try to make things better for you (and even if you aren't a Python user you should care to some extent about it as Instagram runs on Python and thus it is helping to deliver you those cat photos while you're stuck at home ).

Re: What the Heck Is Pyproject.toml?

#185

Post by brettcannon »

scrollaway wrote: post #57
benatkin wrote: post #52

Earlier quoted context omitted.

Here's their justification for using it. It makes sense to me. https://www.python.org/dev/peps/pep-0518/#overview-of-file-f...

It makes sense to use toml. It makes zero sense not to bring pytoml in the stdlib before doing so. The way this was handled is a little absurd.

It was on purpose because TOML has not reached 1.0 yet and breaking people using a module in the stdlib for parsing TOML because TOML itself changed would be an absolute mess. Plus not a single packaging project said it was an issue to either depend on or vendor a TOML parser.

Once TOML hits 1.0 I plan to work on getting a TOML parser into Python's stdlib.

(disclaimer: I am one of the co-authors of PEP 518 that apparently handled things in way that was "a little absurd" .)

Re: What the Heck Is Pyproject.toml?

#186

Post by mixmastamyk »

Supermancho wrote: post #167
mixmastamyk wrote: post #102

Earlier quoted context omitted.

Welcome to HN. They aren't interested in your flippant opinions, man.

The opinions are serious on both sides. If I don't provide criticism, it's a strawman post. Everyone is wrong in criticism here, except when the specific topic is criticism and for that, we get tons of noise about Python. At the same time, it's not a open forum when one side is persecuted.

To expand, you didn't give enough information to decide whether your comment made sense or not. That makes it non-useful in the end. Such comments are downvoted here. I had to learn this myself, as I like to be sarcastic most of the time.

If you don't have something substantial, cited, and/or supported to say, and it is also negative, better to not write anything.

Re: What the Heck Is Pyproject.toml?

#187

Post by mixmastamyk »

pydry wrote: post #136
mixmastamyk wrote: post #103

Earlier quoted context omitted.

Yaml is a big mess. I do really like strict-yaml, however (last time I checked) it is just a hack to simplify the large PyYaml compiled package.

Thanks for the vote of confidence. fwiw version 2.0 of strictyaml will feature its own specification and parser.

Great to hear. I've been manually deactivating almost all of the features of PyYaml for almost a decade now. Over and over. So quite happy someone is taking up the cause.

Re: What the Heck Is Pyproject.toml?

#188

Post by jshen »

viraptor wrote: post #183
jshen wrote: post #182

Earlier quoted context omitted.

It’s really not the same. Gemfile lists the direct dependencies of your project with variable specificity of explicit versions. Gemfile.lock lists all dependencies after resolving your direct dependencies and locks them to specific versions. requirements.txt is some bastardization of both of these combined, and setup.py is neither of these it’s for distribution of modules/packages which Ruby has as well, but it’s not…

You can put dev deps in extras in their own "dev" block. Similar to how gemfile uses groups. Use requirements-dev.txt for them. Requirements for is a full list of dependencies after resolution and their exact versions. (as produced by freeze) The main difference is that requirements is "as installed in current configuration", while gemfile.lock is "for any groups configuration". Again, not as polished experience, but…

But it’s all ad hoc which is problematic. You’re solving it yourself, the tool isn’t solving it. It’s like saying that C is the same as python, you can just write your own garbage collector in C!

Re: What the Heck Is Pyproject.toml?

#189

Post by jshen »

brettcannon wrote: post #184
twic wrote: post #173

Earlier quoted context omitted.

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

I'm not sure how old you are, but if you don't know the name "Borland" you might not realize how novel it is to have a compiler on every major OS. While Python's age means it has been around to see a lot of changes occur, that also means it had pre-existing practices and code to also consider whenever a shift in the industry occurred. Plus in hindsight things look obvious, but during the transition it isn't obvious w…

I’ve been doing this for over 20 years. It’s no excuse, python should have a solution.

Re: What the Heck Is Pyproject.toml?

#190

Post by RMPR »

BiteCode_dev wrote: post #97
earthboundkid wrote: post #50

Earlier quoted context omitted.

I am an experienced Python programmer. I often have to collaborate with people who are not. There is no greater hell than talking them through installing a working Python environment. It’s impossible. Meanwhile, the pip project is full of developers who tell you that your problem is not a problem and you’re discouraging people by pointing out that they’re blame shifting: https://github.com/pypa/pip/issues/4995 I hone…

> There is no greater hell than talking them through installing a working Python environment. It’s impossible. I give a lot of Python professional trainings, and I get to do that regularly, in very diverse situations. It's indeed full of gotchas. Since it's not going to be solved quickly, meanwhile, here is what works if you need to help people setuping python: 1 - Install Python correctly The first version Python do…

Excellent guide, I just found one thing off here:

> If you need to install a tool, such as black, mypy, pylint, etc., outside of a venv, use "--user" to install it for the current user. This requires no admin rights

I think you should add that on Linux distros it's better to use the package manager to install libraries, because a beginner can, and will, have conflicts with (system) packages relying on a particular version of a library. Only use pip if the package is not available, while with the like of Debian, you will have old versions of libraries, I think fast paced distros like Fedora does a good job at providing up to date python libraries with the package manager.

Post reply on HN