7 ms·

It feels like a slight failure that things like this are necessary, especially for a new language. As a Python developer, I am no stranger to slightly ridiculo

It feels like a slight failure that things like this are necessary, especially for a new language. As a Python developer, I am no stranger to slightly ridiculous packaging / environment woes. However Go has 19 years on Python. I understand that they are different languages and ostensibly serve different purposes, but it feels like a shortcoming to me - based on the little Go experience I've had.

jonathanyc 8y ago
I don’t like a lot of Go features but the GOPATH system is really quite good (until you care about pinning versions, when it becomes not worse than Python).
- nostalgeek 8y ago
  GOPATH is going away with vgo so it wasn't really good at all as it forced the developer to adopt a specific folder organization. The fact that go maintainers acknowledged this issue is a sign they are ready to move the language forward.
  - slrz 8y ago
    > forced the developer to adopt a specific folder organization Well, so does C (and basically everything else). Alternatively, you can pass tons of -I and -L flags to your compiler calls but you can do that with Go, too. The point of GOPATH was to make this unnecessary because everything can be deduced from the source code and its location within the file system.
    - sigjuice 8y ago
      You have it backwards. C doesn't restrict where I can keep my source tree.
      - jrockway 8y ago
        I mean, the C toolchain has plenty of baked-in paths where it expects to find something. If project foo depends on project bar, project foo is not automatically going to look at ../bar when building. You either set that up manually, or you put everything in /usr/include and /usr/lib. "Set that up manually" usually consists of an m4 script that takes 15 minutes to run as it tries to look for all the dependencies ("./configure"). It's flexible, but it's not great.
        mathw 8y ago
        But at least that makes it no harder to ask for a specific version of something. Go not having version locks for dependencies by default is a major failing. Fortunately it looks like that will be changing.
faitswulff 8y ago
> As a Python developer, I am no stranger to slightly ridiculous packaging / environment woes. Speaking of which, what is the best way to start a python project in 2018, now? Python's version and dependency management is my least favorite aspect of the language.
- osteele 8y ago
  > Speaking of which, what is the best way to start a python project in 2018 Pipenv[1] and flit[2]. Together, these do most of what npm/yarn provide for a Node.js project. Pipenv for installing packages. It’s a virtual environment manager (like pyenv, virtualenv, venv) that’s aware of and stays in sync with the package requirements list, and supports repeatable builds. It claims to be “officially recommended”, and Travis and Heroku, for example, detect its configuration file. Flit for publishing a package. It’s driven from a declarative project file.[3] EDIT: Added details and a link to [3]. [1] http://docs.pipenv.org/ http://docs.pipenv.org/ [2] http://flit.readthedocs.io/en/latest/ http://flit.readthedocs.io/en/latest/ [3] http://flit.readthedocs.io/en/latest/flit_ini.html http://flit.readthedocs.io/en/latest/flit_ini.html
- undecidabot 8y ago
  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 https://github.com/pypa/pipenv
  - moosingin3space 8y ago
    Nearly all my work at this time is in C++, Rust, Python, and JavaScript. Thanks to pipenv, Python environments finally feel on par with Rust/cargo and NodeJS/Yarn. C++, though, still a mess to get an isolated build environment there. Meson and Bazel are close, so close...
  - akhilcacharya 8y ago
    This sounds brilliant!
  - 8y ago
digianarchist 8y ago
Indeed. There are now many useless repos on Github that are basically unbuildable because dependency lockfiles do not exist for them. I've got to figure out which version was out during the last commit and then pin it. Absolute nightmare.
tazjin 8y ago
> However Go has 19 years on Python Go explicitly dismisses everything learned by the programming language (and tooling) community at large because its authors "know better". There really isn't much to say about Go anymore in my opinion, other than answering the title of this post with "Don't".
- baby 8y ago
  What tooling are they dismissing? Default tooling is pretty much inexistant in other languages.
  - coldtea 8y ago
    >What tooling are they dismissing? A proper package manager, like cargo, npm, pip, composer, maven and the like, for one.
    - baby 8y ago
      Except Cargo, none of these are default toolings and were made by the community.
      - coldtea 8y ago
        Irrelevant, as I didn't say the Go team should build a package manager, just that Go lacks one. And I mean a dominant one -- there's a few attempts for Golang. Default doesn't have to mean "core-team built". All the package managers I've mentioned are de-facto standards for their respective languages.
        baby 8y ago
        Irrelevant
        coldtea 8y ago
        As to what? Or you just wanted to say that? Surely not the the discussion here, which is about "how to start a Go project in 2018" -- or the subthread, about the kind of tooling Go lacks.

jonathanyc 8y ago

I don’t like a lot of Go features but the GOPATH system is really quite good (until you care about pinning versions, when it becomes not worse than Python).

nostalgeek 8y ago
GOPATH is going away with vgo so it wasn't really good at all as it forced the developer to adopt a specific folder organization. The fact that go maintainers acknowledged this issue is a sign they are ready to move the language forward.
- slrz 8y ago
  > forced the developer to adopt a specific folder organization Well, so does C (and basically everything else). Alternatively, you can pass tons of -I and -L flags to your compiler calls but you can do that with Go, too. The point of GOPATH was to make this unnecessary because everything can be deduced from the source code and its location within the file system.
  - sigjuice 8y ago
    You have it backwards. C doesn't restrict where I can keep my source tree.
    - jrockway 8y ago
      I mean, the C toolchain has plenty of baked-in paths where it expects to find something. If project foo depends on project bar, project foo is not automatically going to look at ../bar when building. You either set that up manually, or you put everything in /usr/include and /usr/lib. "Set that up manually" usually consists of an m4 script that takes 15 minutes to run as it tries to look for all the dependencies ("./configure"). It's flexible, but it's not great.
      - mathw 8y ago
        But at least that makes it no harder to ask for a specific version of something. Go not having version locks for dependencies by default is a major failing. Fortunately it looks like that will be changing.

faitswulff 8y ago

> As a Python developer, I am no stranger to slightly ridiculous packaging / environment woes. Speaking of which, what is the best way to start a python project in 2018, now? Python's version and dependency management is my least favorite aspect of the language.

osteele 8y ago
> Speaking of which, what is the best way to start a python project in 2018 Pipenv[1] and flit[2]. Together, these do most of what npm/yarn provide for a Node.js project. Pipenv for installing packages. It’s a virtual environment manager (like pyenv, virtualenv, venv) that’s aware of and stays in sync with the package requirements list, and supports repeatable builds. It claims to be “officially recommended”, and Travis and Heroku, for example, detect its configuration file. Flit for publishing a package. It’s driven from a declarative project file.[3] EDIT: Added details and a link to [3]. [1] http://docs.pipenv.org/ http://docs.pipenv.org/ [2] http://flit.readthedocs.io/en/latest/ http://flit.readthedocs.io/en/latest/ [3] http://flit.readthedocs.io/en/latest/flit_ini.html http://flit.readthedocs.io/en/latest/flit_ini.html
undecidabot 8y ago
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 https://github.com/pypa/pipenv
- moosingin3space 8y ago
  Nearly all my work at this time is in C++, Rust, Python, and JavaScript. Thanks to pipenv, Python environments finally feel on par with Rust/cargo and NodeJS/Yarn. C++, though, still a mess to get an isolated build environment there. Meson and Bazel are close, so close...
- akhilcacharya 8y ago
  This sounds brilliant!
- 8y ago

digianarchist 8y ago

Indeed. There are now many useless repos on Github that are basically unbuildable because dependency lockfiles do not exist for them. I've got to figure out which version was out during the last commit and then pin it. Absolute nightmare.

tazjin 8y ago

> However Go has 19 years on Python Go explicitly dismisses everything learned by the programming language (and tooling) community at large because its authors "know better". There really isn't much to say about Go anymore in my opinion, other than answering the title of this post with "Don't".

baby 8y ago
What tooling are they dismissing? Default tooling is pretty much inexistant in other languages.
- coldtea 8y ago
  >What tooling are they dismissing? A proper package manager, like cargo, npm, pip, composer, maven and the like, for one.
  - baby 8y ago
    Except Cargo, none of these are default toolings and were made by the community.
    - coldtea 8y ago
      Irrelevant, as I didn't say the Go team should build a package manager, just that Go lacks one. And I mean a dominant one -- there's a few attempts for Golang. Default doesn't have to mean "core-team built". All the package managers I've mentioned are de-facto standards for their respective languages.
      - baby 8y ago
        Irrelevant
        coldtea 8y ago
        As to what? Or you just wanted to say that? Surely not the the discussion here, which is about "how to start a Go project in 2018" -- or the subthread, about the kind of tooling Go lacks.