8 ms·

Are there any efforts akin to deno for python? A “burn all the packaging down and start over” path? It’s so thoroughly broken, every day a dev on some team get

Are there any efforts akin to deno for python? A “burn all the packaging down and start over” path? It’s so thoroughly broken, every day a dev on some team gets their poetry env entangled with some system installed python, or numpy suddenly decides all the CI builds will now compile it from scratch on every build, or.. Today it was segfaults on poetry version X on the M1 Mac’s, that went away in version Y but of course version Y broke pandas for the windows devs..

LanternLight83 4y ago
Guix (and maybe nix?) insists on being the "one package manager to rule them all", so Python packages and Rust crates are all re-packaged (sometimes with automated importers). Well I do still occasionally need to package something myself (or cheat pip/requirements.txt it), it definitely covers this "burn it down" philosophy and keeps environments isolated and reproducible.
bayesian_horse 4y ago
I have never used poetry... Mostly I just use conda or plain python envs. Never had those problems like you mention. When using anaconda in the stable channel you'll get a straight-forward "conservative" distribution of all the data science/numerical packages (and more). That's why people often say "just use anaconda", it really is quite simple as long as you don't mess up your stable environments with exotic packages you just want to try out. And it works well on Windows. No idea about Mac and don't care. Python doesn't need "something like deno". All programming languages need package management.
- nonethewiser 4y ago
  How many people work on these projects managed by conda? > And it works well on Windows. No idea about Mac and don't care. Package management is a cross platform problem. You may not need it but that doesn’t make the current solution good.
  - bayesian_horse 4y ago
    There are no "projects managed by conda". You use conda to package or deploy Python software and its dependencies. The Python software itself really doesn't care that much.
IshKebab 4y ago
I doubt that would work. It isn't just the packaging that's broken. The entire import system is broken. I doubt there are more than a handful of developers in the entire world that really understand how Python's `import` works. So to fix it you would need to change that, but then you would break a load of Python libraries which are most of the reason people use Python in the first place. Deno doesn't really have that issue so badly because JS imports are ... not completely sane but they're quite a lot saner. Anyway I think if you were going to break compatibility with Python by fixing the packaging and import system, it's not a much bigger step to fix the rest of Python too and then you have Nim or Lobster.
- mixmastamyk 4y ago
  What problem are you having with imports? Believe I had a few issues in the Py2 times, but things improved and haven't in years.
  - DemocracyFTW2 4y ago
    > > The entire import system is broken > What problem are you having with imports? This is a Python function I wrote some years ago to import a module when given a path: def module_from_path( name, path ): ### thx to https://stackoverflow.com/a/50395128/7568091 ### ### thx to https://stackoverflow.com/a/67692/7568091 ### import importlib import importlib.util spec = importlib.util.spec_from_file_location( name, path ) module = importlib.util.module_from_spec( spec ) sys.modules[ spec.name ] = module spec.loader.exec_module( module ) return importlib.import_module( name ) There are so many conspicuous things about it but to put it short, I should be able to just give a relative or absolute file path, call one method, and be done. Damn all those intermediate steps, and why do I have to name it?
    - IshKebab 4y ago
      Nice idea, unfortunately it will break all static tooling. IDEs, static type checker, linters, etc. I used to work at a company where they had a custom import system and it was a nightmare.
qbasic_forever 4y ago
Develop in a container. It will remove all other issues from your machine/environment and let you declaratively specify the exact environment you need (i.e. packages to install, version of python, etc). Forget all about venv and all the other tools in the python ecosystem--in your container there is _one_ python and you control all of its dependencies.
- nawgz 4y ago
  Pragmatic advice, certainly, but maybe it's missing the point - you shouldn't need a clean OS every time you want to use a new language version. That's a ridiculously large failure of packaging.
  - qbasic_forever 4y ago
    It's core to the design of python right now. Remember when python was designed in the 90s people had big multi-user Unix systems that were bespoke pets. It was assumed that python would be a system-level tool and all packages, etc. would be installed at the system level. Your Python install would be a living thing that was upgraded and administrated like any other software on the machine. Fast forward 30 years and we really don't use most systems like that anymore, especially in production environments. We run things in VMs or containers and build them up from scratch with ease--it's all just cattle. Python hasn't really adapted to that new reality.
    - dvdkon 4y ago
      The fact that many popular Python packages rely on system-level native tools also doesn't help. "Solving Python packaging" isn't just about distributing portable Python source code, that's easy. It's also about packaging and distributing unruly non-Python software for a myriad different platforms, all without user intervention. Sure, the solution's not great, but it's a really hard problem.
    - nonethewiser 4y ago
      Why aren’t virtual environments enough?
blame-troi 4y ago
Every time I get the urge to pick up Python, I find the packaging situation so off putting that I quickly find some other rabbit hole to dive into. I find emacs and vim add on configuration easy and transparent by comparison.
- hodgesrm 4y ago
  Exactly the same thing happened to me recently. I found refuge in Golang. Not my favorite language but it's tough to beat for utilities that you want to distribute quickly.
  - nonethewiser 4y ago
    For all the shit node gets for being too dependency heavy, npm, yarn, pnpm all work exactly how I’d expect.
    - hodgesrm 4y ago
      I love npm. It actually works. ;)
  - noloblo 4y ago
    Not to mention golang sub second compile time and all the productivity boosts coming from that
    - pjmlp 4y ago
      Hardly impressive for anyone that has used compiled languages with modules since the 1980's. What is impressive, is how so many in the industry have forgotten about them.
      - noloblo 4y ago
        With all these years of improving compile times why is haskell compiled time very slow still?
    - 4y ago
cure 4y ago
> A “burn all the packaging down and start over” path? In Python land one of those seems to come along every couple of years. They start over and implement a solution for some subset of the problem space. Then they realize the Python packaging mess is much, much bigger than anticipated and progress stalls. At that point there are 15 partial "standard" packaging solutions for Python, where there were 14 before. None of them are feature complete, and they don't really coexist well or at all. Cue the obligatory https://xkcd.com/927/ https://xkcd.com/927/ and https://xkcd.com/1987/ https://xkcd.com/1987/
rubenfiszel 4y ago
For the need of windmill.dev (OSS retool + FaaS), we support deno and python. To provide that same experience that you're speaking of which is "python run myscript.py" without having to pre-install the dependencies, we wrote our own python parser in Rust which infer the PyPi packages from the imports (and then our workers download them if they are not cached). Here is the code from the parser: https://github.com/windmill-labs/windmill/blob/main/backend/parsers/windmill-parser-py/src/lib.rs https://github.com/windmill-labs/windmill/blob/main/backend/... which we could carve out as a separate module.
tetha 4y ago
Dude, you are dragging up bad thoughts of how finicky it can be to get ansible to work consistently across a number of systems. This is where I kinda regret switching from and miss chef. Pick up an RPM/APT package from vendor, shove it into your package manager, the environment works. It developed a sufficient amount of weird behaviors later on, but that's besides the point. Instead we have a really precise documentation of 4-5 steps to get everything installed in a way that should overall work, and each step is annotated with 4-5 ways that look deceptively good but end up being even more quirky. And when you do all of that, and review it twice, it still doesn't even work consistently across 6 workstations. 3 work the same, 2 have interpreter discovery anomalies, 1 has import conflicts with seemingly unrelated other installed stuff. Whenever I have a working python VM / container build or installation, I kinda feel a need to shut up about my jenga tower because otherwise the universe will find a way specifically to ruin my day. I hate how I have to feel like this about a language I really like.
bb88 4y ago
I don't think you can, nor would you want to at this point. It would just be another standard (ala XKCD-927). Virtualenvs, pip, and wheels have been better than eggs and whatever else came before wheels. Once you set the version of python in the virtualenv and activate it, the right python will always be there. The virtualenv even has an instance of python in it's bin. When that python is run, whatever's installed in the virtualenv comes with it. Poetry, however, does suck even though it's using virtualenv underneath. It's doing frankly too much and seems to have a lot of regressions. In the end it should only be looking at the contents of the virtualenv and using pip to install the correct packages into it. Edited to add: With the last version of poetry causing issues in my development env, I'm about ready to ban it from our team.
- trallnag 4y ago
  Virtualenv has a Python in its bin? Any source on that?
  - jeroenhd 4y ago
    Venvs will actually contain a symlink to a python binary in its venv/bin directory. It doesn't copy a Python executable or download one from the internet as far as I can tell. Still, this means you can install multiple system Python versions and your venv will always contain an executable file of the version the venv was last installed/updated with. ╭─android@localhost ~/tmp/py ╰─$ python3 -m venv testvenv ╭─android@localhost ~/tmp/py ╰─$ file testvenv/bin/python3 testvenv/bin/python3: symbolic link to /data/data/com.termux/files/usr/bin/python3
    - Xophmeister 4y ago
      There’s a command line flag that will make it create an actual copy, rather than a symlink.
      - bb88 4y ago
        It's a copy on windows too.
lmm 4y ago
I got fed up enough with Python dependency management that I started using Maven to build/run my Python programs. It worked well enough, but having to package the whole world myself got old, and I realised I preferred Scala anyway.
- kjkjadksj 4y ago
  This is literally why conda exists…
BiteCode_dev 4y ago
We used the "burn all" strategy I/O during the 2 to 3 transitions. People were not impressed. Hence the previous article (https://bitecode.substack.com/p/relieving-your-python-packaging-pain https://bitecode.substack.com/p/relieving-your-python-packag...) advocating to go back to the basics yourself. See the reddit thread to witness exactly this in action: https://www.reddit.com/r/Python/comments/124hktv/comment/je5ihet/?context=3 https://www.reddit.com/r/Python/comments/124hktv/comment/je5...
rcme 4y ago
Python is only popular because of the packages. I doubt many would use Python if they didn't get to use PyTorch, etc. Another thing that makes Python different than JS is that many of the most widely used Python libraries are really Python wrappers around native code. Of course some Node libraries rely on node-gyp and other native tooling, but many applications are pure-JS. Porting native libraries is bound to be challenging unless a similar native API is provided.
- v3ss0n 4y ago
  lets compare apples to apples. 1 - Scientific Libraries are written C python use as glue code. 2 - Almost all of web frameworks are written in Python except Blacksheep where core parts are written in C. From that presepective , most python libs are written in python only.
kjkjadksj 4y ago
Conda has none of these issues. Its so easy to use and maintain dependencies imo.
deaddodo 4y ago
This is what pip+venv were built for. The alternatives are from people who wanted a "better" or "preferred" experience. Or to solve a specific problem that the in-built tools haven't. If you get any python job, you'd get a lot of side-eyes for not knowing of/how to use and initialize basic venv package sets. Even if the shop uses conda.
noloblo 4y ago
Use haskell ocaml or racket - golang to try a different paradigm that's not a holy mess Python's environment management is just the tip of the ice berg Dynamic typing Gil Speed is slow at best Async streams having its set of non tractable issues Debugging by printing pdb all over and breaking
noloblo 4y ago
Just create a folder for your project And then Python3 -m venv envdir source envdir/bin/activate bin/python3 -m pip install --upgrade pip And similarly the rest of the packages needed for the project This does not mess up the system library or other python projects
- BeFlatXIII 4y ago
  > source envdir/bin/activate This step is the least intuitive until you've done it enough times that it's muscle memory.
nonbirithm 4y ago
With the sheer brokenness of Python packaging I wish that the Python 2->3 transition had been between two completely different languages, such that the entire thing could have been thrown away. Yet because there was breakage, but not enough breakage to amount to moving towards a better rewrite, nobody's ever going to attempt a true Python 4. They blew their chance. Now we have a never ending train of hotshot developers that think they can "solve" Python packaging with another tool, without realizing that you can't design a tool to fix a broken 15-year-old system. It's not just a "there are now X competing standards" issue, it's also the fact that anyone who makes an earnest attempt is doomed. They will never be able to get it past the point of universally good enough. I lament the fact that I'm dragged back into the Python ecosystem every time I need to do something with a PyTorch-based tool someone spent years of effort building. I would never recommend the language to a newcomer. Ruby pollutes the global namespace, and Gemfiles execute arbitrary code, but at least with Ruby there's Gem, and then there's Bundler, and nobody complains. Will we forever be beholden to the mistaken decisions of the original developers in the early 90's, just because Python is simply too widespread? Because even people like me who detest the packaging experience are forced to go back there because nobody's going to rewrite the hottest ML project in Elixir or something? Even the simple mistakes like putting venv files in Scripts/ instead of bin/ forcing one to work around it in cross-platform CI make no sense in hindsight. Nobody remembers why it was made that way after so long. Now it just floats over you like a spectre.
MonaroVXR 4y ago
So, wait a minute I get that everybody can choose a laptop. But if this holding you back, you can a Linux vm or a Linux distro.
d0mine 4y ago
"There are only two kinds of languages: the ones people complain about and the ones nobody uses." Can it be better--yes. Is it worse than _any_ other language's packaging if it were to scale to the number/kind of cases Python supports/used--no. "thoroughly broken" is useless. Are there bugs--most definitely yes. Do report them, or even help fixing them if you care. There are many many different use-cases where different approaches are preferable (no size fits all). Personally, most most of the time packaging is a non-issue e.g., pinning versions and cache are highly recommended for CI to avoid unnecessary surprises, flakiness.
- bheadmaster 4y ago
  "There are only two kinds of languages: the ones people complain about and the ones nobody uses." - the guy who created C++ I always bring up Go in such arguments - according to the survey [0] done by the Go team, 93% of Go users are satisfied with the language. [0] https://go.dev/blog/survey2022-q2-results https://go.dev/blog/survey2022-q2-results
  - d0mine 4y ago
    When if ever Go becomes as widespread as either C++ or Python, then we talk
    - bheadmaster 4y ago
      C++ being horrible has less to do with its widespreadedness and more with the committee-driven design and being intentionally designed as a C derivative in order to gain maximum backwards compatibility.

LanternLight83 4y ago

Guix (and maybe nix?) insists on being the "one package manager to rule them all", so Python packages and Rust crates are all re-packaged (sometimes with automated importers). Well I do still occasionally need to package something myself (or cheat pip/requirements.txt it), it definitely covers this "burn it down" philosophy and keeps environments isolated and reproducible.

bayesian_horse 4y ago

I have never used poetry... Mostly I just use conda or plain python envs. Never had those problems like you mention. When using anaconda in the stable channel you'll get a straight-forward "conservative" distribution of all the data science/numerical packages (and more). That's why people often say "just use anaconda", it really is quite simple as long as you don't mess up your stable environments with exotic packages you just want to try out. And it works well on Windows. No idea about Mac and don't care. Python doesn't need "something like deno". All programming languages need package management.

nonethewiser 4y ago
How many people work on these projects managed by conda? > And it works well on Windows. No idea about Mac and don't care. Package management is a cross platform problem. You may not need it but that doesn’t make the current solution good.
- bayesian_horse 4y ago
  There are no "projects managed by conda". You use conda to package or deploy Python software and its dependencies. The Python software itself really doesn't care that much.

IshKebab 4y ago

I doubt that would work. It isn't just the packaging that's broken. The entire import system is broken. I doubt there are more than a handful of developers in the entire world that really understand how Python's `import` works. So to fix it you would need to change that, but then you would break a load of Python libraries which are most of the reason people use Python in the first place. Deno doesn't really have that issue so badly because JS imports are ... not completely sane but they're quite a lot saner. Anyway I think if you were going to break compatibility with Python by fixing the packaging and import system, it's not a much bigger step to fix the rest of Python too and then you have Nim or Lobster.

mixmastamyk 4y ago
What problem are you having with imports? Believe I had a few issues in the Py2 times, but things improved and haven't in years.
- DemocracyFTW2 4y ago
  > > The entire import system is broken > What problem are you having with imports? This is a Python function I wrote some years ago to import a module when given a path: def module_from_path( name, path ): ### thx to https://stackoverflow.com/a/50395128/7568091 ### ### thx to https://stackoverflow.com/a/67692/7568091 ### import importlib import importlib.util spec = importlib.util.spec_from_file_location( name, path ) module = importlib.util.module_from_spec( spec ) sys.modules[ spec.name ] = module spec.loader.exec_module( module ) return importlib.import_module( name ) There are so many conspicuous things about it but to put it short, I should be able to just give a relative or absolute file path, call one method, and be done. Damn all those intermediate steps, and why do I have to name it?
  - IshKebab 4y ago
    Nice idea, unfortunately it will break all static tooling. IDEs, static type checker, linters, etc. I used to work at a company where they had a custom import system and it was a nightmare.

qbasic_forever 4y ago

Develop in a container. It will remove all other issues from your machine/environment and let you declaratively specify the exact environment you need (i.e. packages to install, version of python, etc). Forget all about venv and all the other tools in the python ecosystem--in your container there is _one_ python and you control all of its dependencies.

nawgz 4y ago
Pragmatic advice, certainly, but maybe it's missing the point - you shouldn't need a clean OS every time you want to use a new language version. That's a ridiculously large failure of packaging.
- qbasic_forever 4y ago
  It's core to the design of python right now. Remember when python was designed in the 90s people had big multi-user Unix systems that were bespoke pets. It was assumed that python would be a system-level tool and all packages, etc. would be installed at the system level. Your Python install would be a living thing that was upgraded and administrated like any other software on the machine. Fast forward 30 years and we really don't use most systems like that anymore, especially in production environments. We run things in VMs or containers and build them up from scratch with ease--it's all just cattle. Python hasn't really adapted to that new reality.
  - dvdkon 4y ago
    The fact that many popular Python packages rely on system-level native tools also doesn't help. "Solving Python packaging" isn't just about distributing portable Python source code, that's easy. It's also about packaging and distributing unruly non-Python software for a myriad different platforms, all without user intervention. Sure, the solution's not great, but it's a really hard problem.
  - nonethewiser 4y ago
    Why aren’t virtual environments enough?

blame-troi 4y ago

Every time I get the urge to pick up Python, I find the packaging situation so off putting that I quickly find some other rabbit hole to dive into. I find emacs and vim add on configuration easy and transparent by comparison.

hodgesrm 4y ago
Exactly the same thing happened to me recently. I found refuge in Golang. Not my favorite language but it's tough to beat for utilities that you want to distribute quickly.
- nonethewiser 4y ago
  For all the shit node gets for being too dependency heavy, npm, yarn, pnpm all work exactly how I’d expect.
  - hodgesrm 4y ago
    I love npm. It actually works. ;)
- noloblo 4y ago
  Not to mention golang sub second compile time and all the productivity boosts coming from that
  - pjmlp 4y ago
    Hardly impressive for anyone that has used compiled languages with modules since the 1980's. What is impressive, is how so many in the industry have forgotten about them.
    - noloblo 4y ago
      With all these years of improving compile times why is haskell compiled time very slow still?
  - 4y ago

cure 4y ago

> A “burn all the packaging down and start over” path? In Python land one of those seems to come along every couple of years. They start over and implement a solution for some subset of the problem space. Then they realize the Python packaging mess is much, much bigger than anticipated and progress stalls. At that point there are 15 partial "standard" packaging solutions for Python, where there were 14 before. None of them are feature complete, and they don't really coexist well or at all. Cue the obligatory https://xkcd.com/927/ https://xkcd.com/927/ and https://xkcd.com/1987/ https://xkcd.com/1987/

rubenfiszel 4y ago

For the need of windmill.dev (OSS retool + FaaS), we support deno and python. To provide that same experience that you're speaking of which is "python run myscript.py" without having to pre-install the dependencies, we wrote our own python parser in Rust which infer the PyPi packages from the imports (and then our workers download them if they are not cached). Here is the code from the parser: https://github.com/windmill-labs/windmill/blob/main/backend/parsers/windmill-parser-py/src/lib.rs https://github.com/windmill-labs/windmill/blob/main/backend/... which we could carve out as a separate module.

tetha 4y ago

Dude, you are dragging up bad thoughts of how finicky it can be to get ansible to work consistently across a number of systems. This is where I kinda regret switching from and miss chef. Pick up an RPM/APT package from vendor, shove it into your package manager, the environment works. It developed a sufficient amount of weird behaviors later on, but that's besides the point. Instead we have a really precise documentation of 4-5 steps to get everything installed in a way that should overall work, and each step is annotated with 4-5 ways that look deceptively good but end up being even more quirky. And when you do all of that, and review it twice, it still doesn't even work consistently across 6 workstations. 3 work the same, 2 have interpreter discovery anomalies, 1 has import conflicts with seemingly unrelated other installed stuff. Whenever I have a working python VM / container build or installation, I kinda feel a need to shut up about my jenga tower because otherwise the universe will find a way specifically to ruin my day. I hate how I have to feel like this about a language I really like.

bb88 4y ago

I don't think you can, nor would you want to at this point. It would just be another standard (ala XKCD-927). Virtualenvs, pip, and wheels have been better than eggs and whatever else came before wheels. Once you set the version of python in the virtualenv and activate it, the right python will always be there. The virtualenv even has an instance of python in it's bin. When that python is run, whatever's installed in the virtualenv comes with it. Poetry, however, does suck even though it's using virtualenv underneath. It's doing frankly too much and seems to have a lot of regressions. In the end it should only be looking at the contents of the virtualenv and using pip to install the correct packages into it. Edited to add: With the last version of poetry causing issues in my development env, I'm about ready to ban it from our team.

trallnag 4y ago
Virtualenv has a Python in its bin? Any source on that?
- jeroenhd 4y ago
  Venvs will actually contain a symlink to a python binary in its venv/bin directory. It doesn't copy a Python executable or download one from the internet as far as I can tell. Still, this means you can install multiple system Python versions and your venv will always contain an executable file of the version the venv was last installed/updated with. ╭─android@localhost ~/tmp/py ╰─$ python3 -m venv testvenv ╭─android@localhost ~/tmp/py ╰─$ file testvenv/bin/python3 testvenv/bin/python3: symbolic link to /data/data/com.termux/files/usr/bin/python3
  - Xophmeister 4y ago
    There’s a command line flag that will make it create an actual copy, rather than a symlink.
    - bb88 4y ago
      It's a copy on windows too.

lmm 4y ago

I got fed up enough with Python dependency management that I started using Maven to build/run my Python programs. It worked well enough, but having to package the whole world myself got old, and I realised I preferred Scala anyway.

kjkjadksj 4y ago
This is literally why conda exists…

BiteCode_dev 4y ago

We used the "burn all" strategy I/O during the 2 to 3 transitions. People were not impressed. Hence the previous article (https://bitecode.substack.com/p/relieving-your-python-packaging-pain https://bitecode.substack.com/p/relieving-your-python-packag...) advocating to go back to the basics yourself. See the reddit thread to witness exactly this in action: https://www.reddit.com/r/Python/comments/124hktv/comment/je5ihet/?context=3 https://www.reddit.com/r/Python/comments/124hktv/comment/je5...

rcme 4y ago

Python is only popular because of the packages. I doubt many would use Python if they didn't get to use PyTorch, etc. Another thing that makes Python different than JS is that many of the most widely used Python libraries are really Python wrappers around native code. Of course some Node libraries rely on node-gyp and other native tooling, but many applications are pure-JS. Porting native libraries is bound to be challenging unless a similar native API is provided.

v3ss0n 4y ago
lets compare apples to apples. 1 - Scientific Libraries are written C python use as glue code. 2 - Almost all of web frameworks are written in Python except Blacksheep where core parts are written in C. From that presepective , most python libs are written in python only.

kjkjadksj 4y ago

Conda has none of these issues. Its so easy to use and maintain dependencies imo.

deaddodo 4y ago

This is what pip+venv were built for. The alternatives are from people who wanted a "better" or "preferred" experience. Or to solve a specific problem that the in-built tools haven't. If you get any python job, you'd get a lot of side-eyes for not knowing of/how to use and initialize basic venv package sets. Even if the shop uses conda.

noloblo 4y ago

Use haskell ocaml or racket - golang to try a different paradigm that's not a holy mess Python's environment management is just the tip of the ice berg Dynamic typing Gil Speed is slow at best Async streams having its set of non tractable issues Debugging by printing pdb all over and breaking

noloblo 4y ago

Just create a folder for your project And then Python3 -m venv envdir source envdir/bin/activate bin/python3 -m pip install --upgrade pip And similarly the rest of the packages needed for the project This does not mess up the system library or other python projects

BeFlatXIII 4y ago
> source envdir/bin/activate This step is the least intuitive until you've done it enough times that it's muscle memory.

nonbirithm 4y ago

With the sheer brokenness of Python packaging I wish that the Python 2->3 transition had been between two completely different languages, such that the entire thing could have been thrown away. Yet because there was breakage, but not enough breakage to amount to moving towards a better rewrite, nobody's ever going to attempt a true Python 4. They blew their chance. Now we have a never ending train of hotshot developers that think they can "solve" Python packaging with another tool, without realizing that you can't design a tool to fix a broken 15-year-old system. It's not just a "there are now X competing standards" issue, it's also the fact that anyone who makes an earnest attempt is doomed. They will never be able to get it past the point of universally good enough. I lament the fact that I'm dragged back into the Python ecosystem every time I need to do something with a PyTorch-based tool someone spent years of effort building. I would never recommend the language to a newcomer. Ruby pollutes the global namespace, and Gemfiles execute arbitrary code, but at least with Ruby there's Gem, and then there's Bundler, and nobody complains. Will we forever be beholden to the mistaken decisions of the original developers in the early 90's, just because Python is simply too widespread? Because even people like me who detest the packaging experience are forced to go back there because nobody's going to rewrite the hottest ML project in Elixir or something? Even the simple mistakes like putting venv files in Scripts/ instead of bin/ forcing one to work around it in cross-platform CI make no sense in hindsight. Nobody remembers why it was made that way after so long. Now it just floats over you like a spectre.

MonaroVXR 4y ago

So, wait a minute I get that everybody can choose a laptop. But if this holding you back, you can a Linux vm or a Linux distro.

d0mine 4y ago

"There are only two kinds of languages: the ones people complain about and the ones nobody uses." Can it be better--yes. Is it worse than _any_ other language's packaging if it were to scale to the number/kind of cases Python supports/used--no. "thoroughly broken" is useless. Are there bugs--most definitely yes. Do report them, or even help fixing them if you care. There are many many different use-cases where different approaches are preferable (no size fits all). Personally, most most of the time packaging is a non-issue e.g., pinning versions and cache are highly recommended for CI to avoid unnecessary surprises, flakiness.

bheadmaster 4y ago
"There are only two kinds of languages: the ones people complain about and the ones nobody uses." - the guy who created C++ I always bring up Go in such arguments - according to the survey [0] done by the Go team, 93% of Go users are satisfied with the language. [0] https://go.dev/blog/survey2022-q2-results https://go.dev/blog/survey2022-q2-results
- d0mine 4y ago
  When if ever Go becomes as widespread as either C++ or Python, then we talk
  - bheadmaster 4y ago
    C++ being horrible has less to do with its widespreadedness and more with the committee-driven design and being intentionally designed as a C derivative in order to gain maximum backwards compatibility.