4 ms·

Go may be unique in being the only ecosystem built after Python that can't claim it avoided Python's packaging disasters.

mdtusz 7y ago
Cargo works pretty well too.
- takeda 7y ago
  Cargo is not from Go
  - jessaustin 7y ago
    As a name for a package manager, "cargo" certainly appears more suitable for "go" than for "rust".
takeda 7y ago
I believe Python suffers from no leadership in that space (everyone creates their own packaging, every tutorial advocates something different, many tutorials are outright wrong). There was also a bad decision of using Python code for installation (setup.py) instead of a declarative language. Most of that issues are actually fixed in setuptools if you put all settings in setup.cfg and just call empty setup() in setup.py. Like here: https://github.com/takeda/example_python_project/blob/master/setup.cfg https://github.com/takeda/example_python_project/blob/master...
throwaway894345 7y ago
How do you figure? Go's packaging is wayyyy better than Python's. I've done considerable work with each and while Go's ecosystem has warts here and there, it's far from disastrous. I can't say that about Python. If nothing else, Go lets you distribute a static binary with everything built in, including the runtime. Python's closest analog is PEX files, but these don't include the runtime and often require you to have the right `.so` files installed on your system, and they also don't work with libraries that assume they are unpacked to the system packages directory or similar. In general, it also takes much longer to build a PEX file than to compile a Go project. Unfortunately, PEX files aren't even very common in the Python ecosystem.
- morelisp 7y ago
  In the context of > Pip/Poetry/VirtualEnv "packaging" refers to the way the language manages dependencies during the build and import process, not how you distribute programs you have built. Python has a deservedly poor reputation here, having churned through dozen major overlapping different-but-not-really tools in my decade and a half using it. And even the most recent one is only about a year into wide adoption, so I wouldn't count on this being over. Go tried to ignore modules entirely, using the incredibly idiosyncratic GOPATH approach, got (I think) four major competing implementations within half as long, finally started converging, then Google blew a huge amount of political capital countermanding the community's decision. My experience with Go modules has been mostly positive, but there's no really major new idea in it that needed a decade to stew nor the amount of emotional energy. (MVS is nice but an incremental improvement over lockfiles, especially as go.sum ends up morally a lockfile anyway.)
  - throwaway894345 7y ago
    I fully agree with this assessment, but I don’t see how this puts Python’s story on par with Go’s. While GOPATH was certainly idiosyncratic, it generally just worked for me. While go modules aren’t perfect and the history was frustrating, they generally work fine for me. Python feels like an uphill battle by comparison.
    - morelisp 7y ago
      If Go sticks with modules and doesn't keep making significant changes (e.g. the proxy introduced 1.13 was not handled well), then it will be better than Python. But if Python finally "picks" poetry, sticks with it for a few years and incrementally fixes problems rather than rolling out yet another new tool, that will also be better. You can only identify the end of the churn for either retroactively. Python just looks worse right now because it's been around longer.
      - jatone 7y ago
        difference here is track record. go: tends to wait and implement something once the problem is understood. took 2 years after go maintainers decided to solve the dependency issues. and as of the latest release its finally been labelled production ready. and honestly the proxy issues were not real. go modules was still optional. you could just turn it off. python is how old now? couple decades? and it has only gotten worse over time.

mdtusz 7y ago

Cargo works pretty well too.

takeda 7y ago
Cargo is not from Go
- jessaustin 7y ago
  As a name for a package manager, "cargo" certainly appears more suitable for "go" than for "rust".

takeda 7y ago

I believe Python suffers from no leadership in that space (everyone creates their own packaging, every tutorial advocates something different, many tutorials are outright wrong). There was also a bad decision of using Python code for installation (setup.py) instead of a declarative language. Most of that issues are actually fixed in setuptools if you put all settings in setup.cfg and just call empty setup() in setup.py. Like here: https://github.com/takeda/example_python_project/blob/master/setup.cfg https://github.com/takeda/example_python_project/blob/master...

throwaway894345 7y ago

How do you figure? Go's packaging is wayyyy better than Python's. I've done considerable work with each and while Go's ecosystem has warts here and there, it's far from disastrous. I can't say that about Python. If nothing else, Go lets you distribute a static binary with everything built in, including the runtime. Python's closest analog is PEX files, but these don't include the runtime and often require you to have the right `.so` files installed on your system, and they also don't work with libraries that assume they are unpacked to the system packages directory or similar. In general, it also takes much longer to build a PEX file than to compile a Go project. Unfortunately, PEX files aren't even very common in the Python ecosystem.

morelisp 7y ago
In the context of > Pip/Poetry/VirtualEnv "packaging" refers to the way the language manages dependencies during the build and import process, not how you distribute programs you have built. Python has a deservedly poor reputation here, having churned through dozen major overlapping different-but-not-really tools in my decade and a half using it. And even the most recent one is only about a year into wide adoption, so I wouldn't count on this being over. Go tried to ignore modules entirely, using the incredibly idiosyncratic GOPATH approach, got (I think) four major competing implementations within half as long, finally started converging, then Google blew a huge amount of political capital countermanding the community's decision. My experience with Go modules has been mostly positive, but there's no really major new idea in it that needed a decade to stew nor the amount of emotional energy. (MVS is nice but an incremental improvement over lockfiles, especially as go.sum ends up morally a lockfile anyway.)
- throwaway894345 7y ago
  I fully agree with this assessment, but I don’t see how this puts Python’s story on par with Go’s. While GOPATH was certainly idiosyncratic, it generally just worked for me. While go modules aren’t perfect and the history was frustrating, they generally work fine for me. Python feels like an uphill battle by comparison.
  - morelisp 7y ago
    If Go sticks with modules and doesn't keep making significant changes (e.g. the proxy introduced 1.13 was not handled well), then it will be better than Python. But if Python finally "picks" poetry, sticks with it for a few years and incrementally fixes problems rather than rolling out yet another new tool, that will also be better. You can only identify the end of the churn for either retroactively. Python just looks worse right now because it's been around longer.
    - jatone 7y ago
      difference here is track record. go: tends to wait and implement something once the problem is understood. took 2 years after go maintainers decided to solve the dependency issues. and as of the latest release its finally been labelled production ready. and honestly the proxy issues were not real. go modules was still optional. you could just turn it off. python is how old now? couple decades? and it has only gotten worse over time.