> I actually wrote a Python solution at first, but having to install the pip dependencies on my clean varnish box seemed like a bad idea and it keep breaking in odd ways which I didn’t feel like debugging. Amen! This is why I am learning Go at the moment and considering using it instead of Python for admin and data processing tasks on a fleet of servers. The single binary deployment makes it a lot easier for users to…
I don't get it... Can't you just use a virtualenv? Then there's no worry about namespace pollution or conflicts between dependencies of different projects.
Processing 40TB of code from 10M projects with a dedicated server and Go
51–60 of 83 posts
Re: Processing 40TB of code from 10M projects with a dedicated server and Go
#52> I actually wrote a Python solution at first, but having to install the pip dependencies on my clean varnish box seemed like a bad idea and it keep breaking in odd ways which I didn’t feel like debugging. Amen! This is why I am learning Go at the moment and considering using it instead of Python for admin and data processing tasks on a fleet of servers. The single binary deployment makes it a lot easier for users to…
Re: Processing 40TB of code from 10M projects with a dedicated server and Go
#53Earlier quoted context omitted.
I don't get it... Can't you just use a virtualenv? Then there's no worry about namespace pollution or conflicts between dependencies of different projects.
Installing a full virtualenv with all related libraries just to run one script is kind of ridiculous. The server might have the wrong Python version available (2.x vs 3.x, multiple evolutions of 3.x with big features added in each point release). Et cetera, et cetera. Or you could just do it with bash or a static Go binary and be done with it. Portable, works pretty much everywhere.
Re: Processing 40TB of code from 10M projects with a dedicated server and Go
#54> I actually wrote a Python solution at first, but having to install the pip dependencies on my clean varnish box seemed like a bad idea and it keep breaking in odd ways which I didn’t feel like debugging. Amen! This is why I am learning Go at the moment and considering using it instead of Python for admin and data processing tasks on a fleet of servers. The single binary deployment makes it a lot easier for users to…
Yeah, I was writing a Docker image built around Prometheus' jmx_exporter intended to be used as a mixin for our Java apps, and part of what I needed to do was provide a simple script to preprocess separate config files to produce the config used by jmx_exporter. My initial thought was Python, but it needed a couple of 3rd party dependencies, and there wasn't an overly clean _and_ simple way to copy the script in from…
Did you consider, and stop me if this suggestion is completely wild, Java?
Re: Processing 40TB of code from 10M projects with a dedicated server and Go
#55Earlier quoted context omitted.
I don't get it... Can't you just use a virtualenv? Then there's no worry about namespace pollution or conflicts between dependencies of different projects.
virtualenv still requires internet access. You'd have to create a venv on destination machine and pip install your packages in. You can't scp a local venv onto destination machine and have it work.
I had heard that the Python packaging and deployment story had got a lot better in recent years, but this sounds like it still falls far short of table stakes.
Re: Processing 40TB of code from 10M projects with a dedicated server and Go
#56Earlier quoted context omitted.
I don't get it... Can't you just use a virtualenv? Then there's no worry about namespace pollution or conflicts between dependencies of different projects.
This is becoming a parody of software engineering. People are now irrationally scared of using dynamic libraries, OS packages and even directories, like virtualenvs. Instead, a simple solution is replaced with containers, or by rewriting tons of code in the new hyped language. Are we trying to create job security through unnecessary complexity?
Re: Processing 40TB of code from 10M projects with a dedicated server and Go
#57As much as I love the confirmation that .yml is the correct extension, I’m most amazed by the fact that there’s over a TRILLION lines of code public on GitHub. That’s an astronomical number. And that’s only what we can all see. Can’t imagine how much more is private. Also, it look’s like 20% of code is comments. Which feels just about right.
.yml only makes sense in a word where every other extension is three letters. With variably length extensions, there isn't a good reason to not just use the full name.
Re: Processing 40TB of code from 10M projects with a dedicated server and Go
#58Earlier quoted context omitted.
I don't get it... Can't you just use a virtualenv? Then there's no worry about namespace pollution or conflicts between dependencies of different projects.
This is becoming a parody of software engineering. People are now irrationally scared of using dynamic libraries, OS packages and even directories, like virtualenvs. Instead, a simple solution is replaced with containers, or by rewriting tons of code in the new hyped language. Are we trying to create job security through unnecessary complexity?
Re: Processing 40TB of code from 10M projects with a dedicated server and Go
#59- The largest .c file is actually the CATH database, not sure why it has that extension
- The large .cpp file is actually C++ but has a kind of 'data as code' approach defining bonds between atoms
Re: Processing 40TB of code from 10M projects with a dedicated server and Go
#60Earlier quoted context omitted.
virtualenv still requires internet access. You'd have to create a venv on destination machine and pip install your packages in. You can't scp a local venv onto destination machine and have it work.
I am an utter noob at Python packaging, but i would like to learn more, so excuse the basic question, but: why doesn't it work? And is there anything in the ecosystem which is like that, but does work? I had heard that the Python packaging and deployment story had got a lot better in recent years, but this sounds like it still falls far short of table stakes.
We're finally getting around to migrating away, and we've settled on Twitter's github.com/pantsbuild/pants which is like Google's Bazel except that it's jankier in every way _except_ that Pants supports Python while Bazel doesn't (Bazel advertises Python support, but it doesn't work as the many Python 3 issues in their issue tracker can attest). The nicest thing about Pants is that it builds pex files (github.com/pantsbuild/pex) which are executable zip files that ship all of your dependencies except the Python interpreter and shared objects.
I'm still not very satisfied with this solution, and it's still far, far worse than Go's dependency management and packaging model, but it's a dramatic improvement over Pipenv, virtualenv, etc (gives us both reproducibility and performance).