Update on packagingvanity URLs | Dagger | Page 1

terse pine Oct 21, 2022, 8:44 PM

#

Proof, from a brand new repo:

# brand new module
$ go mod init github.com/aluzzardi/importtest
go: creating new go.mod: module github.com/aluzzardi/importtest
go: to add module requirements and sums:
    go mod tidy

# buildkit crap
$ go mod edit -replace=github.com/docker/docker=github.com/docker/docker@v20.10.3-0.20220414164044-61404de7df1a+incompatible

# `main.go` is importing the SDK, `go mod tidy` finds everything
$ go mod tidy
go: finding module for package go-vanity-test.netlify.app/dagger/sdk/go/dagger
go: downloading go-vanity-test.netlify.app/dagger/sdk/go v0.1.0-alpha.10
go: found go-vanity-test.netlify.app/dagger/sdk/go/dagger in go-vanity-test.netlify.app/dagger/sdk/go v0.1.0-alpha.10
go: downloading go-vanity-test.netlify.app/dagger v0.3.0-alpha.8

#

(go-vanity-test.netlify.app/dagger is my own dagger.io/dagger for testing)

#

(in the snippet above: Go SDK was released as v0.1.0-alpha.10, dagger as v0.3.0-alpha.8)

deft sable Oct 21, 2022, 8:58 PM

#

I guess Option X means same version for all SDKs since we'll use tags? If we distribute the python / node packages via git, it means bumping all SDKs everytime there is a change.

#

Given we might release often initially it might be ok. And it does not prevent us to split the repos later (the upgrade migration for users will be a pain though...)

clear inlet Oct 21, 2022, 9:02 PM

#

In option X do we need to version EVERYTHING in lockstep or only go sdk + engine?

If it’s everything, we will have a cue sdk version 0.3 that depends on engine 0.2. Which is not a deal breaker but we need to be ok with communicating that (can’t sweep it under the rug)

terse pine Oct 21, 2022, 9:05 PM

#

Yeah, that's the only difference between the options:

Option X: same version, same go.mod

Option Z: different versions, different go.mod

#

both options have the same import path

clear inlet Oct 21, 2022, 9:08 PM

#

in option X what would be the import path?

#

oh I see /sdk/go/dagger

#

😖

#

so only way to get sdk at dagger.io/dagger is to split repos?

terse pine Oct 21, 2022, 9:10 PM

#

yes

clear inlet Oct 21, 2022, 9:22 PM

#

Sorry if I asked this before but: wouldn't it be possible to just move the engine go.mod from the root to ./engine? That way there would be 2 go.mods, but they would be side by side rather than nested.

Aside from changing import paths from github.com/dagger/dagger to github.com/dagger/dagger/engine, everything would be pretty smooth: one monorepo, separate versioning of everything, short vanity url for the sdk... No?

I'm guessing I'm missing something important

obsidian cedar Oct 21, 2022, 9:26 PM

#

@clear inlet I'm pretty sure the main sticking point is that sub folders + vanity urls don't work nicely together. So I think that would just move the problem around.

clear inlet Oct 21, 2022, 9:26 PM

#

Ah ok, I read "submodules" but maybe it was really "modules in a subfolder"

obsidian cedar Oct 21, 2022, 9:26 PM

#

This details the problem, as I understand it. https://github.com/golang/go/issues/34055

GitHub

cmd/go: allow serving module under the subdirectory of git reposito...

If you head to https://github.com/nhooyr/websocket presently, you'll get blasted with a massive root directory listing, mostly due to all the Go files. It's obnoxious. Compare that ...

obsidian cedar Oct 21, 2022, 9:27 PM

#

clear inlet Ah ok, I read "submodules" but maybe it was really "modules in a subfolder"

Yeah, I think that's what doesn't work well.

clear inlet Oct 21, 2022, 9:27 PM

#

got it

#

https://tenor.com/view/tigger-tigger-winnie-the-pooh-tigger-sad-disappear-gif-25009198

Tenor

terse pine Oct 21, 2022, 10:15 PM

#

obsidian cedar <@488409085998530571> I'm pretty sure the main sticking point is that sub folder...

Yeah

import <vanity url>/<path to go.mod within repo root>

#

that's the constant

#

go get supports github.com/dagger/dagger/foo/bar

I thought the vanity URL could respond with github.com/dagger/dagger/foo/bar

However, it can only respond with github.com/dagger/dagger

The path within the repo is determined by the user import

fiery kindle Oct 21, 2022, 11:15 PM

#

Modules in subfolders are fine as long as you have complete control over who imports those packages. Otherwise you lock yourself in forever ot that particular structure.

For example if you add a new module under a path that was already a module before and two different packages import those two modules, Go will go nuts saying that in one case it's a module, but not in the other and it won't be able to decide which module to import in order to use that package.

I've burnt myself quite a few times with this, so unless it's absolutely necessary or you aren't absolutely sure there won't be any changes in the module structure, I would avoid modules in subdirectories.

#

I wrote about vanity imports a while ago: https://sagikazarmark.hu/blog/vanity-import-paths-in-go/

+1 for using vanity imports!

Márk Sági-Kazár

Vanity import paths in Go

Recently I migrated one of my libraries (Emperror) to a vanity import path.
Although the migration itself was easy (took less than one day), making the decision,
thinking it through from every angle to make sure existing applications don’t break, wasn’t.
I did a lot of research to find the right migration path, URL, tooling
and I decided to shar...

noble tapir Nov 14, 2024, 3:08 AM

#

Resurrecting this 2 year old thread for some good news - support for vanity URLs pointing to subpaths is on the way: https://go-review.googlesource.com/c/go/+/625577

Once this ships we can get rid of the dagger/dagger-go-sdk repo. Might simplify our release process a bit? /cc @daring wing

#Update on packagingvanity URLs