About APIs down his price, entire yells free shuts guy

ben_lubar

@cartman82 said:

You can do the same thing with node with a few commands you get out of the box. Similar with python + pip.

So your complaint about Go's package management is that it's not centralized enough?

sloosecannon

Java too! (for the most part - there's no CLI but there might be a GUI?) Maven is awesome

cartman82

@ben_lubar said:

So your complaint about Go's package management is that it's not centralized enough?

My complaint is that I want my package management like I want my version control - painless and out of my way.

I want to go to node's website, learn the 3 npm commands I need so I can manage my project and then get to my main task - which is programming.

I don't want to spend the first 2 days slowly realizing why I shouldn't use go's broken native system (which helpfully isn't mentioned anywhere in the official docs). Then 2 more days doing scientific research into a 100 different third party package managers, each with its own quirks, each using its own system, each incompatible with others. And then, after finally finding one that sucks only a little bit, waste ADDITIONAL FUCKING TIME debugging it and hacking around its issues.

I think that's not too much to ask for a language released last year.

ben_lubar

@cartman82 said:

I think that's not too much to ask for a language released last year.

Oh, so you're in a time pod. That makes more sense, then.

cartman82

@ben_lubar said:

Oh, so you're in a time pod. That makes more sense, then.

Fine a few years ago.

Whatever.

Doesn't excuse the crapfest "package manager" it ships with.

ben_lubar

@cartman82 said:

My complaint is that I want my package management like I want my version control

Okay, so why is it a problem to have package management that is version control, then?

cartman82

@ben_lubar said:

Okay, so why is it a problem to have package management that is version control, then?

Explain.

ben_lubar

Ok, so let's say I want to download and install this command:

delve/cmd/dlv/main.go at master · derekparker/delve

Delve is a debugger for the Go programming language. - derekparker/delve

I would type this into my terminal:

go get github.com/derekparker/delve/cmd/dlv

That would download and compile all the dependencies it needs and install the command in $GOPATH/bin.

What's the issue?

cartman82

Sure, for academic jerking around, that's all swell.

But what happens when you want to save your project to source control? Add all that junk in?
If not, what if the dependency changes the API you depend on?
What if multiple dependencies depend on a different version of a common dependency?
Without some kind of version pinning, all dependencies would have to package all the third party code they depend on, which would generate git trees gigabytes in size.

Don't act like an idiot when you're not.

Also, get your head out of Go's ass and smell the air. Go has good points, but dependency management is not one of them.

ben_lubar

@cartman82 said:

Without some kind of version pinning,

You mean like git submodules?

cartman82

@ben_lubar said:

You mean like git submodules?

Explain how would that work

ben_lubar

Let's say I want to use the current version of termbox-go without any of the future updates.

git submodule add https://github.com/nsf/termbox-go.git vendor/github.com/nsf/termbox-go

And then git will track the checked-out revision of that repository. If I want to update the dependency, all I need to do is git pull inside the vendor thing and git commit inside my own project.

cartman82

That uses the new GO15VENDOREXPERIMENT flag, which I already said makes things bearable.

It still lacks deduping and it will take a while for all the packages to switch to this system, but I can work with that.

The question is, why the fuck it took them years to get here, and it will take them years still until they even approach the level where everyone else is.

EDIT

Also note that this

go get github.com/derekparker/delve/cmd/dlv

doesn't get you the setup you demonstrated above.

So there's still a LOT of work to be done.

LB_

Heads up: I've never used Go and I'm not even talking about what Go does or does not do.

@cartman82 said:

Install a package and all its dependencies using nice CLI or GUI commands

Installing packages is something the build process should do, isn't it?

@cartman82 said:

Pin installed packages to versions you want

Again, shouldn't the code or the build process decide which version(s) it wants?

@cartman82 said:

Save package requirements in some kind of a list, that you can version control with the project

Again, shouldn't the code or the build process determine which dependencies are needed? Those are both in version control, right?

@cartman82 said:

Painlessly restore requirements as needed, so you don't need to clog up your git with vendors' junk

Why would you store dependencies in your project's directory!? They should be cached locally in some place accessible to all projects (e.g. some folder in your user home directory, or maybe in a system folder).

@cartman82 said:

Separate your code from dependencies, so you can keep the vendor stuff out of git using a sane .gitignore

Again, I strongly disagree with storing dependencies anywhere near my project's directory.

@cartman82 said:

Intelligently de-dupe duplicate dependencies

Um, what? Isn't that what local caching does? I've never seen that be a problem before...

My personal ideal version control manager only facilitates lookup and local caching. Just have the build system or code ask for the dependencies and versions you want, and if they aren't already stored in the global cache, they get downloaded. You can nuke the global cache at any time you want and rebuild your current project to get only the dependencies you need. No metadata required, no junk in version control, and easy to pick up your project on a new machine without even needing to know what dependencies are needed.

TwelveBaud

@LB_ said:

Installing packages is something the build process should do, isn't it?

Making it a nice CLI/GUI command makes it easier to shove into a build process.@LB_ said:

Again, shouldn't the code or the build process decide which version(s) it wants?

Yes, which is why your code has a package manifest, that you create, with the acceptable versions you want. Those packages have their own manifests that say what they want. The code should just use the dependency with impunity, and the build process doesn't even need to be aware of it, only that whatever "package restore" command exists unbreaks it.@LB_ said:

Why would you store dependencies in your project's directory!? They should be cached locally in some place accessible to all projects (e.g. some folder in your user home directory, or maybe in a system folder).

That's what pip and maven do by default, and what pear and nuget and a few others can do if configured properly. The other school of thought is that they should live near (but not in) the project so that they can be moved with the project if needed.@LB_ said:

Um, what? Isn't that what local caching does? I've never seen that be a problem before...

It should, but the Go, RubyGems, et cetera method is to have a "vendor" folder dumping ground, each subfolder of which has its own "vendor" subfolder dumping ground, until the crap is neck-deep.

powerlord

@TwelveBaud said:

That's what pip and maven do by default, and what pear and nuget and a few others can do if configured properly. The other school of thought is that they should live near (but not in) the project so that they can be moved with the project if needed.

I was under the impression that this is what nuget does by default. I know if I check out a Prism project I was working on, Visual Studio bugs me about downloading Prism from nuget.

TwelveBaud

By default, NuGet stores packages in a solution-level folder called "packages". It downloads them there when you build the project either just before MSBuild runs, or as part of MSBuild as a build step (for you probably the latter). Using a nuget.config file either in the .nuget folder or in your home folder, you can instead specify an absolute or different solution-relative path to use, which can be a central cache.

powerlord

@TwelveBaud said:

By default, NuGet stores packages in a solution-level folder called "packages". It downloads them there when you build the project either just before MSBuild runs, or as part of MSBuild as a build step (for you probably the latter). Using a nuget.config file either in the .nuget folder or in your home folder, you can instead specify an absolute or different solution-relative path to use, which can be a central cache.

Note: I've done basically no special configuration for this... I created the solution and projects in Visual Studio 2015 Update 5 and used Nuget to install Prism.Wpf and RestSharp using Install-Package.

Each of my projects (this is a multi-project solution) has a packages.config file:

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="CommonServiceLocator" version="1.3" targetFramework="net46" />
  <package id="Prism.Core" version="6.1.0" targetFramework="net46" />
  <package id="Prism.Mef" version="6.1.0" targetFramework="net46" />
  <package id="Prism.Wpf" version="6.1.0" targetFramework="net46" />
  <package id="RestSharp" version="105.2.3" targetFramework="net45" />
</packages>

(Note: This is a WPF application.)

I was apparently wrong about it prompting me to install packages every time I checked it out... it's only once per computer that it asks. I assuming Visual Studio 2013 Update 5 / NuGet is putting these in the global cache all on its own.

Edit: I have no idea why Prism says it's targetting net46... I should fix that at some point.

TwelveBaud

Yep, this is all expected. Your last sentence isn't quite right though; it's putting them in the solution-level cache. If you were to open a different solution that used Prism, it'd bug you to download it for that one too. The .gitignore and .tfignore that Visual Studio generate for you exclude that folder, so it doesn't get checked in, but it's right there next to the projects.

NuGet looks at your project settings (specifically which multi-targeting pack is set for .NET Runtime version) and infers a value for that from there; if the package doesn't provide one specific to that pack, but does provide one that's compatible (net20 or net40 for example) it'll silently use that instead. When you change which framework you're targeting, NuGet should bug you to Update-Package -Reinstall, and that will take care of that.

dkf

@cartman82 said:

If not, what if the dependency changes the API you depend on?

If they aren't using semantic versioning and break an API frequently in minor releases, then don't use that shit! Seriously, if someone really can't grasp that API stability matters (modulo changes that are purely extensive of the API) they'll fuck you over again and again if you depend on them. Yes, this makes things quite a bit more conservative and slower to change. That's the whole point.

On the flip side, if you depend on something in an alpha release and that breaks on you, you've only got yourself to blame. And the problem with using git for all this is that there's basically no releasing mechanism there. People can use propagating tags to do that sort of thing, but it's kind-of rare in the wild. So go's effectively got everyone using stuff that is pre-alpha.

Nice one. We'll be seeing this on the front page in a few years I'd guess.

cartman82

@dkf said:

And the problem with using git for all this is that there's basically no releasing mechanism there. People can use propagating tags to do that sort of thing, but it's kind-of rare in the wild. So go's effectively got everyone using stuff that is pre-alpha.

If only Go supported depending on a tag, or a branch or even a fucking commit.

Nope. It's master or nothing. Yeeehaawww!

LB_

@cartman82 said:

If only Go supported depending on a tag, or a branch or even a fucking commit.

Nope. It's master or nothing. Yeeehaawww!

Jesus! That's pretty bad. In my language it will be the exact opposite: depending on a branch will be impossible, you'll have to use a tag or commit.

dkf

@LB_ said:

In my language it will be the exact opposite: depending on a branch will be impossible, you'll have to use a tag or commit.

May I commend tags, and commend requiring the tags to be in a pre-defined format? Yes, developers will grumble. For about a minute. Then they'll get on with doing it. Also, make your code assume that version numbers are semantic version numbers. Again, some people will COMPLAIN about it (more likely management and marketing this time) but sticking with that will strongly encourage good habits.

All proposed with lots of experience, both good and bad. Be strict now and everyone will play nicely.

kt_

@hifi said:

Does he make ~~sweet love~~hot Cosby with the Go compiler or something?

FTFY