111–117 of 117 posts
Earlier quoted context omitted.
All of the reasons I listed...?
But npm does all of those...
> It's distasteful of Go to impose a filesystem layout.
> To achieve [self-contained dependenceis] with Go, one has to set a different GOPATH per project, and then checkout the project deep into that root.
> Given that Go doesn't really do package versioning...
Earlier quoted context omitted.
It's still a bit new, but I think pipenv [1] is the new standard now. No need to directly work with pip or virtualenv anymore, and the equivalent requirements file works more like npm/yarn. [1] https://github.com/pypa/pipenv
With all due respect to the Python community, and without intending this as an insult per se, if this really is the "current recommendation", the Python community is in no position to be criticizing the Go community on this point. This is about the fourth answer I've heard in the past 10 years. I've been programming off and on in Python for at least 15 years and I've never heard of this tool. Out of morbid curiosity,…
The Hitchhiker's Guide to Python[1] (HHGTP) encapsulates a lot of standard tools and best practices. I've been recommending it to students for a few years now. Last year it listed virtualenv, venv, pyenv, etc.; now it recommends just pipenv.
HHGTP also has sections on "Packaging Your Code" and "Freezing Your Code". I think what you're asking about is referred to there as "freezing". The "Freezing" section of HHGTP lists some Windows tools, and contains a table comparing them. There doesn't look to be a single accepted one.
A G^nP post did criticize Go compared to Python, but I don't believe the author speaks for “the Python community”.
It's distasteful of Go to impose a filesystem layout. Any other language that I work with understands that dependencies should be self-contained within the project folder. Each project has it's own set of dependencies that have been tested to work together. The user can select where to checkout the project, or even have multiple copies of the same project lying around. To achieve the same thing with Go, one has to se…
I made[1] a zsh hook some time ago that allowed you to have per-project GOPATH. At the root of the project I just have to do `echo 'github.com/username/package' > .gopkg` and after that, for everything I do under that directory tree, GOPATH will be automatically set to something like `export GOPATH="$(dirname .gopkg)/.gopath"`. I don't use zsh anymore though. [1]: https://gist.github.com/strkek/294c2f5e6fe94b8303b512…
[1]: https://direnv.net/
Earlier quoted context omitted.
What tooling are they dismissing? Default tooling is pretty much inexistant in other languages.
> What tooling are they dismissing? A proper package manager, like cargo, npm, pip, composer, maven and the like, for one.
Earlier quoted context omitted.
To be fair, go code at Google doesn't use the standard directory structure. I had all my go code in one directory and which files were part of which package was all defined in a build file. What exists in the public world of go was simply what the go team wanted for go and not a compromise to fit in with other systems at Google. I think the fact that you end up with what looks like a monolithic repository is just a c…
> In the end ~/go doesn't look a lot different than the @INC path that points to something in your home directory, or /usr/include, /usr/lib, and /usr/bin in a pure C system. Well, yes and no, and that's the only thing I don't like about GOPATH: that your source code is not in GOPATH, but in `$GOPATH/src`. I'm not against GOPATH per-se because I'm already used to other PATHs; I'm just against it not behaving like tho…