6 ms·
It's weird how personal this is. Sometimes I wonder if it comes down to familiarity. I've been using Python professionally since 2000 and have never run into i
by js2 3y ago
It's weird how personal this is. Sometimes I wonder if it comes down to familiarity.
I've been using Python professionally since 2000 and have never run into issues with its tooling. It's even easier these days: "python -m venv" and then pip are all I need in 99% of use cases. For local development I use direnv + pyenv. I typically develop on macOS and deploy to either macOS or Linux. I previously gave pipenv a try but found it to be brittle and more trouble than it was worth. I haven't used poetry just because I haven't had the need.
Conversely, I regularly run into trouble with ruby. Here's a recent example where I had to contribute a patch to pre-commit to get ruby to install gems where pre-commit wanted it to:
https://github.com/pre-commit/pre-commit/pull/2905 https://github.com/pre-commit/pre-commit/pull/2905
I got so annoyed with bundler I wrote a simple shell script to provide the moral equivalent of Python venvs to gem:
https://gist.github.com/jaysoffian/3c67711d3f00c364365905d877cc4af4 https://gist.github.com/jaysoffian/3c67711d3f00c364365905d87...
All that said, these are just minor annoyances. The only tooling I truly despise is Gradle and especially everything around the Android Gradle Plugin.
- movpasd 3y agoI don't have any issues with Python's packaging ecosystem anymore, having settled comfortably into a pyenv+virtualenv+pip-tools as my "stack" after going around the block a few times. But even so, I must recognise how awful the experience is for new users. It's taken me years to settle into this system, and it can take half a day to get someone up to speed with these tools if they haven't used them. I also work a lot with non-developers who need to use or contribute to Python models, so that doesn't help — but I bet it would take an order of magnitude less time to get them up to speed with something like cargo. Coaching them has helped me see how user-hostile the process is to beginners. It also doesn't help how infectious "all-in-one" Python distributions like Anaconda can be, to the point that whenever anyone has an unexpected issue one of my first reflexes is to check their PATH. The fact that Rust has a widespread default toolchain multiplexer completely solves this issue. I appreciate that maintaining such a toolchain is work, and there is value as well in the diversity and choice of an open ecosystem. But perhaps building is one place where first-class support by the reference implementation creates a worthwhile tradeoff.
- systems 3y agowhy do sometimes people say things like "and it can take half a day to get someone up to speed with these tools if they haven't used them" half a day is like almost no time at all half a day is just few hours, how is this a long time .. how is this any time at all makes me doubt myself a bit, am i too mediocre to think that way the previous line make more sense to me "It's taken me years to settle into this system" , now this is more like it
- carbotaniuman 3y agoI don't think it's half a day to get proficient, it's half a day to hack something half working together so they're unblocked and can do the other stuff they want to do.
- throwawaymaths 3y agoAnd then another half a day to get pissed off because you don't remember what settings are/are not in your venv and trying to exit and/or get back into the venv (assuming no prior experience with venv) Fundamentally venv breaks your conceptions of what a shell is through cleverness, and that's a problem for people who are new.
- deleted 3y ago[deleted]
- codeflo 3y agoHalf a day to get something running that's a "one off" for you is insane. With a compiled language project, I'd download a binary. In Python, I need to reproduce the developer's setup. And I've yet to find two different Python projects where the official build instructions are compatible -- each one recommends a different environment virtualizer, a different runtime, different settings, and different C libraries that aren't part of the virtualized environment.
- earthboundkid 3y agoThe thing that drives me insane about Python packaging is the degree of Stockholm Syndrome. PYTHON PACKAGING HAS KIDNAPPED YOU. YOU DON’T ACTUALLY LOVE IT. None of Go, JavaScript, or Rust require a half a day to figure out packaging. Don’t defend Python. Push for it to change or leave it behind.
- scruple 3y agoI've used Python intermittently throughout my career but today it is my primary language. I've also never really had issues and have pretty much always stuck with the basics. I'm not on a very large team, though. Only 5 developers will ever touch the Python we're writing. I've only ever worked on Python on very small teams, so I wonder if that factors in?
- nologic01 3y agoI think complaining about Python's tooling has become like complaining about the weather in some cold and rainy country. Good for chit-chat and noding in resigned consensus. In the meantime I cant recall any instance in the last five years (at least) where a project would fail to get going based on a simple venv and pip setup. An exception is CUDA but I think we can agree this is not what you need to setup every day. I wonder if that benign view due to Linux and people experiencing something very different in other OS's.
- pharmakom 3y agoHow do you build a bundle for Linux from macOS? In my experience this is only possible with Docker, and is a huge weakness of the Python ecosystem. Would love to hear solutions.
- Tainnor 3y ago> I got so annoyed with bundler I wrote a simple shell script to provide the moral equivalent of Python venvs to gem: This already exists: https://rvm.io/gemsets https://rvm.io/gemsets Most people don't use it because they haven't felt the need. Bundler already makes sure it loads exactly the right versions of gems for your project, so there's no need to isolate them from each other.