Earlier quoted context omitted.
When I was a Python dev, I never saw that happen in ten years or so of work. Pip freeze and virtualenv just worked for me. I will say, though, that this only accounts for times where you’re not upgrading dependencies. Where I’ve always run into issues in Python was when I decided to upgrade a dependency and eventually trigger some impossible mess.
Upgrading dependencies is fraught in all languages.
Learning Go as a Python Developer: The Good and the Bad
161–170 of 269 posts
Re: Learning Go as a Python Developer: The Good and the Bad
#162i dragged my feet on go for a long time. i also thought that skipping go and moving to rust was the play. a few years later, i still write python often, but i don’t build systems with it. python i now use like bash, to glue things together and automate random things. it’s a fantastic language and i will never drop it. the verbosity of go is the biggest hurdle for a pythonista. the thought of giving up context manager…
I've rebuilt multiple projects written in python/php/perl originally in go instead and it's just great how much more performant these comparatively are... Just way lower resource usage and the programs work faster now. It's worth it to consider the switch. One of the things that go is really good for is the amount you can get done without having to deviate that far from the standard library. A lot of churn in updatin…
i enjoy refactoring with type safety and using gopls and ide completion instead of external docs. i used to constantly read boto3 docs in a browser, now i use gopls in my ide.
frontend dev can be sane[1] too! my default setup is a go lambda with an spa frontend inlined into an html file.
the lambda zip contains two files:
- ./main
- ./index.html.gz
Re: Learning Go as a Python Developer: The Good and the Bad
#163I hated the "damnable use requirement" (the error you get on unused imports) for years, but I've been keeping a count of how many bugs they've caught (I was surprised the first time this happened) and I'm up to 3-4 now. What people who code in Go seriously do is just hook `goimports` up to their editor, and then never think about this again.
Unused imports or variables being errors is the most idiotic and overrated paper cut ever implemented in compilers. In no universe it is a good idea.
I posit there are actually no or very few bugs it catches, and in exchange it ruins people's iterative development, flow and hyperfocus states when experimenting, because poor compiler can't deal with an unused import, fix it now or else. Now we need an IDE setup to deal with this? And why the hell isn't this a feature that can be turned off?
If only I could throw the person that invented this crap into the flaming sun.
Re: Learning Go as a Python Developer: The Good and the Bad
#164Earlier quoted context omitted.
- Poetry is a 3rd party package manager, I'm sure it's great but it's not widely used (yet) - Pip freeze just pins all dependencies at once to requirements.txt - I don't know what "vendoring in dependency code" means - I've never used pipreqs in my life (and 80% of my work has been in Python) - Virtualenvs are just a convenient way to keep project runtimes separated And for 90% of Python projects in existence the fol…
"Vendoring" means including the library in your package. So instead of listing it in requirements.txt, you copy the code of the library.
Re: Learning Go as a Python Developer: The Good and the Bad
#165Earlier quoted context omitted.
This comment section itself clearly shows how crazy dependency and environment management is in Python. In this thread alone, we've received instructions to... - poetry - "Just pin the dependencies and use Docker" - pip freeze - Vendoring in dependency code - pipreqs - virtualenv This is simply a mess and it's handled much better in other languages. I manage a small agency team and there are some weeks where I feel l…
The real issue is that you can't have multiple versions installed at the same time. if you could import numpy==3.2 it'd solve many problems.
Re: Learning Go as a Python Developer: The Good and the Bad
#166Earlier quoted context omitted.
> > - pip freeze > all this does it just lists currently installed packages in a form that can be automatically read by pip Are you referring to version specifiers[1] being optional or is there something more to versions that I don't understand? PEP 440 is a wall of text, maybe I should get around to reading it sometime. [1] https://packaging.python.org/en/latest/glossary/#term-Versio...
I mean pip freeze outputs packages and their versions in machine readable form that can be read and installed by pip install -r requirements.txt
Re: Learning Go as a Python Developer: The Good and the Bad
#167Earlier quoted context omitted.
Sometimes I feel people are using Python very differently than me. I just use pip freeze and virtualenv (these are Python basics, not some exotic tools) and I feel it works great. Granted, you don't get a nice executable, but it's still miles ahead of C++ (people literally put their code into header files so you don't have to link to a library), and even modern languages like rust (stuff is always broken, or I have s…
Comparing anything to C++ is a very low bar. I have rarely encountered issues in rust. Most rust crates stick to semver so you know when there will be a breaking change. My rust experience with Cargo can only be described as problem free(though I only develop for x86 linux). As for pip freeze and virtualenv things start to fall apart especially quickly when you require various C/C++ dependencies (which in various par…
Yes 100 times. That can be incredibly frustrating. During the last year I've used a large (and rapidly evolving) C++ project (with many foss C/C++ dependencies) with Python bindings. We've collectively wasted sooo many hours on dependency issues in the team.
Long compilation times contribute considerably to slow down the feedback loop when debugging the issues.
Re: Learning Go as a Python Developer: The Good and the Bad
#168Earlier quoted context omitted.
This comment section itself clearly shows how crazy dependency and environment management is in Python. In this thread alone, we've received instructions to... - poetry - "Just pin the dependencies and use Docker" - pip freeze - Vendoring in dependency code - pipreqs - virtualenv This is simply a mess and it's handled much better in other languages. I manage a small agency team and there are some weeks where I feel l…
- Poetry is a 3rd party package manager, I'm sure it's great but it's not widely used (yet) - Pip freeze just pins all dependencies at once to requirements.txt - I don't know what "vendoring in dependency code" means - I've never used pipreqs in my life (and 80% of my work has been in Python) - Virtualenvs are just a convenient way to keep project runtimes separated And for 90% of Python projects in existence the fol…
Re: Learning Go as a Python Developer: The Good and the Bad
#169Earlier quoted context omitted.
Solving environment | Solving environment / Solving environment - Solving environment \ Solving environment | ... One day it takes 10 seconds, next month it takes 10 minutes, and the month after that it takes 30 minutes and then fails entirely.
Are you using conda-forge? Solving from over 6TBs of packages can take quite a while. Conda-forge builds everything . This isn't a criticism, but because of that the number of packages is massive.
To answer your question: yes, we were using conda-forge, and then when it stopped building we moved to a mix of conda and a critical subchannel, and then a major GIS library broke on conda and stayed that way for months so we threw in the towel and just used pip + a few touch-up scripts. Now that everyone else has followed suit, pip is the place where things "just work" so now we just use pip, no touchups required.