Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rfc: enforce package name == last element of import path in maketx addpkg #1571

Open
thehowl opened this issue Jan 23, 2024 · 0 comments
Open
Labels
gno-proposal Gnolang change proposals 📦 ⛰️ gno.land Issues or PRs gno.land package related

Comments

@thehowl
Copy link
Member

thehowl commented Jan 23, 2024

There is an "unwritten convention" in Go whereby the last element of the import path should be the same as the name of the package, although nothing forbids this from happening:

package hello // import "howl.moe/goodbye"

Users of the package will then have hello as the "default" identifier for that package, unless overridden in the import:

package main

import (
    "howl.moe/goodbye" // this will use identifier "hello"
    goodbye "howl.moe/goodbye" // this will use "goodbye"
)

I think this has caused reasonable confusion in the past, and adds a layer of complexity when parsing the source code. As such, I propose restricting adding packages to the chain only if the identifier in the package clause matches the last slash-separated element of the import path, ie. goodbye for howl.moe/goodbye.

While I don't think there is a strong argument to be made about including this in the language/VM itself (it would mean that the code parsing is aware of the import path, which shouldn't necessarily be the case), I think it makes sense to have this as a restriction for addpkg. This way we can, as human readers, be sure that the identifier for imported packages will match the last item of the import path.

Upgrade concerns

See-also #694 for a discussion on upgrading packages and realms.

The canonical way to have a v2 import path in Go is the following: github.com/my/import/path/v2. Under this restriction, the package identifier should be v2. To overcome this, I propose two alternatives:

  • Correctly handle /v[1-9][0-9]* suffixes as a special case.
  • Use a different "version syntax" altogether, such as gno.land/my/import/path@2.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gno-proposal Gnolang change proposals 📦 ⛰️ gno.land Issues or PRs gno.land package related
Projects
Status: 🌟 Wanted for Launch
Development

No branches or pull requests

2 participants