Live data from Hacker News

What the Heck Is Pyproject.toml?

snarky.ca

141–150 of 199 posts

Re: What the Heck Is Pyproject.toml?

#141
post #108

Earlier quoted context omitted.

> Python serves several huge ones: web, datascience, 3d graphics, sysadmin... all with different needs, different conventions, different “standard” tools to do this and that. Them having different conventions and standard tools is the failure, not a constraint. What are the different needs that these ecosystems have which mean they couldn't use a common package manager? I don't believe there are any.

For instance, in the scientific computing world, compiled extensions are hugely important, whereas they're relatively rare in web development. There's probably no logical reason why a single common package manager for these domains is impossible. But they have different priorities, and people write tools that solve their own problems. Who is going to decide which package managers are unnecessary, and convince all of…

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

Re: What the Heck Is Pyproject.toml?

#142

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…

> 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.

Re: What the Heck Is Pyproject.toml?

#143
post #110

Earlier quoted context omitted.

Ah, so Python is for small and slow, doesn't seem to be the best in everything after all. Which brings us back to "nice scripting and introduction to programming language".

Yup. Clearly no one is going to be able to convince you otherwise, so is there much point in you continuing to read this thread?

Indeed.

Re: What the Heck Is Pyproject.toml?

#144

Earlier quoted context omitted.

> 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…

This is an awesome summary that should be placed on the python.org front page instead of all the fuzzy stuff that's there right now.

I've been tasked to make a PR for the pypa website with something like this. If it doesn't get merged, I'll still have a copy of it to some website as a single page. I bought usepyhton.info for this purpose, since pyformat.info did a great job.

Re: What the Heck Is Pyproject.toml?

#145

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…

I agree. This really seems like high impact too. A first party, supported solution would solve this mess. Getting the Python dependency build story under control I would include in this category. In this department, I think Conda shows the way. They leverage Azure Pipelines to build much of the c dependencies ahead of time, and just send binaries down the pipe (at least, that's the high level overview as I understand…

There has been a long debate about it between core devs, pypa members, conda CEO and a few key elements of the community recently.

The conclusion has been that:

- distributing story is handled ok, but distributing program is not.

- python has some unique problems due to its popularity, diversity of user base and long history

- the py command should be available everywhere

- communication on best practices is lacking, and people mixes project deployment, dependency management, lib packaging and program distribution

- the way python deals with imports is the root of all evils, not the packaging system, which actually is a consequence of it

The best course of action to take is still not clear though, as creating yet another layer on top of the mess is probably not the right thing to do.

Re: What the Heck Is Pyproject.toml?

#146

Earlier quoted context omitted.

Do note that Python the language is developed by a separate group as Python the packaging ecosystem. So even when Guido was a BDFL he completely stayed out of the packaging situation. And there is a packaging BDFL, but there's a severe lack of time and effort in the form of volunteers to tackle a lot of the projects, big or small. Plus rolling these things out takes years and it takes even longer to gain traction as…

Definitely, it is always good to keep in the back of our minds that FOSS is developed by people in their free time and on a volunteering basis. No one owes us anything. No one should feel entitled. I am sorry if my complains come out as such. Python runs the world and it is because of the contributions of many amazing people.

> Definitely, it is always good to keep in the back of our minds that FOSS is developed by people in their free time and on a volunteering basis.

Please don't over-generalize. Volunteering is not the only way FOSS is developed. E.g. the Linux kernel, Gitlab, Firefox, Golang main tools…

Re: What the Heck Is Pyproject.toml?

#147

I don’t want to be too negative, and I realize this isn’t an option for everyone ... but seriously, just use conda if you can. Judging from comments here and in the past, we all know packaging is one of Python’s Achilles’ heels. I spent a couple years bouncing around with pyenv/pipenv, then poetry, then back. I lovingly followed all the flamewars here and on github. Ultimately, I realize now, I laboured under the con…

I've had the opposite experience. I used conda for several years, primarily for data science, but regularly ran into problems with packages not working, updates for packages bring severely delayed, and issues with conda itself. Switched to pyenv+virtualenv 18 months ago and haven't had a single issue. I believe both of our stories. I just always wonder how this happens that two people have such opposite experiences.

Because conda and other tools don't mix.

If you only use conda, it works.

If you start to pip install or use venv, it will break at some point.

Re: What the Heck Is Pyproject.toml?

#148

Is toml even supported in the standard library? This seems just bizarre. Python's really overtaking node for massive churn. I feel like an old guy when peers say, "don't use virtual environment use pipenv." then someone says no no don't even use that, use poetry. Etc. I think about 50% of why I enjoy, in my soul, about Rust when I'm hacking away and personal goofs is that the dependency and project management system…

Rust management system is first class because the language has been designed from scratch 10 years ago.

Python has been around since 1991. It came out before installing dependencies from internet was a thing. It had support for Windows XP, Atari, Solaris. You gotta be able to pip install stuff that are written in C (numpy) or in Fortran (scipy). It had been implemented in the JVM, .net, and Python itself using pypy.

All those years, what we knew about or needed from packaging system changed, and the tooling followed. We had easy_install, then setuptools, then distutils, then distutils2, the pip + setuptools again. We had virtualenv, then venv.

You cannot break from the past easily, especially on such a popular language, with half of it's user not even being devs.

Re: What the Heck Is Pyproject.toml?

#149
post #90

Earlier quoted context omitted.

I would not use Node as an example of good packaging. It really hasn't been that long since left-pad. Then there's the fact that you still have multiple different tools to do the same thing (npm vs. yarn) and the end result node_modules/ is a fucking mess anyways. find node_modules/ -name "node_modules" | wc -l 327

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.

Re: What the Heck Is Pyproject.toml?

#150

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…

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…

> "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."

I too regularly have to do the same thing, but I have absolutely no issues getting newcomers onto the python ecosystem. You download the installer, you run it, and it works. Or you apt/yum install it with no issues.

Setting up a dev environment for them though is where some hassle comes. VSCode being a particularly bad one in that regard. But with Pycharm, newcomers are on boarded in a matter of minutes.

Post reply on HN