3 ms·

This problem is not unique to Python, it’s just the proliferation of incompatible tools that makes Python quite so annoying to use. I’ve found that none of thi

by cpfohl 3y ago

This problem is not unique to Python, it’s just the proliferation of incompatible tools that makes Python quite so annoying to use. I’ve found that none of this is really an issue if you provide a container as a dev environment. Before someone accuses me of “yet another standard”ing this, it’s my standard across all my programming environments. It’s not a silver bullet, especially with Apple silicon Docker can be a massive pain in the butt, but it works for me. Inside the container I can be guaranteed that only a single Python version is installed (correctly) and packages are installed in a standard way from a package file. Adding a package can be scripted so that it gets executed inside the container and adds it to you packages file. The other massive benefit is that your local machine needs no locally installed tools other than docker (or podman, or whatever). this works for me and my team it’s not perfect, but it is a complex problem.

crabbone 3y ago
It's not "this" problem. It's many problems together. Some of them, while maybe not unique to Python are completely preventable. Where the right thing to do was obvious, but Python core dev decided to cut corners, or do nothing etc. So, we need to be fair and put the blame where it belongs. Python packaging format didn't just "happen", it was designed... by a bunch of half-wits, but that's exactly the problem! Python import system didn't "just happen", it was designed, by mostly the same kind of people -- and, again, that's the problem! If anyone wanted to put a good effort and thinking into designing packaging format and the import system, they'd realized that they need to deal with multiple versions of the same package somehow, they would've realized that they need to distinguish between binary distribution and source / documentation / data packages, that they need a reliable tool for installing those packages. But nothing of the kind was done. Every "development" in this area was incrementally adding more technical debt. Is technical debt a new thing? -- surely not. Is it preventable? -- well, not so much, but being cognizant of it one could establish certain practices to mitigate the adverse effects. And this, this particular thing, has never been done in Python. Is this a common failure? -- well, again yes, but this doesn't vindicate Python core developers, they are just as guilty as a bunch of other people who suck at programming.

by cpfohl 3y ago

crabbone 3y ago

It's not "this" problem. It's many problems together. Some of them, while maybe not unique to Python are completely preventable. Where the right thing to do was obvious, but Python core dev decided to cut corners, or do nothing etc. So, we need to be fair and put the blame where it belongs. Python packaging format didn't just "happen", it was designed... by a bunch of half-wits, but that's exactly the problem! Python import system didn't "just happen", it was designed, by mostly the same kind of people -- and, again, that's the problem! If anyone wanted to put a good effort and thinking into designing packaging format and the import system, they'd realized that they need to deal with multiple versions of the same package somehow, they would've realized that they need to distinguish between binary distribution and source / documentation / data packages, that they need a reliable tool for installing those packages. But nothing of the kind was done. Every "development" in this area was incrementally adding more technical debt. Is technical debt a new thing? -- surely not. Is it preventable? -- well, not so much, but being cognizant of it one could establish certain practices to mitigate the adverse effects. And this, this particular thing, has never been done in Python. Is this a common failure? -- well, again yes, but this doesn't vindicate Python core developers, they are just as guilty as a bunch of other people who suck at programming.