Move ghw from jaypipes to go-hardware Github Organization #359

Activity

1. ffromani commented on Jan 4, 2024

   

   ffromani

   on Jan 4, 2024

   Collaborator

   More actions

   I've been thinking about doing this move for a little while. Some organizations (including my own employer, Microsoft), avoid importing libraries from personal Github organizations. They consider (wrongly, IMHO) repositories falling under personal Github accounts to be "less than" repositories that are maintained by multiple parties in a separate Github Organization.

   I share the same experience; in my case repos backed by orgs (vs backed by individuals) are "just" strongly preferred. The perception is that the bus factor for orgs is bigger than for individuals, but there's actually a ton of nuance here; nevertheless, this perception exists and we need to deal with it.

   I have owned the go-hardware dot com and go-hardware dot org domains for quite some time and I have created a Github Organization called "go-hardware". I'm strongly considering "moving" the github.com/jaypipes/ghw repository to the github.com/go-hardware Github Organization and getting ghw to a 1.0 release under the github.com/go-hardware umbrella.

   I'd like thoughts on this, particular on whether it's worth it, considering we have 1500+ Github stars and >440 projects that import the ghw codebase.

   We could minimize disruption by making a clean break from the github.com/jaypipes/ghw codebase and making a completely new github.com/go-hardware/ repository with the inspection/discovery code that is already in github.com/jaypipes/ghw. We would leave github.com/jaypipes/ghw for some amount of time but mark the README as the code has moved to another location and then eventually archive the repository?

   I think this is the best approach because this is the one which best serves the current userbase. We can wrap up the most urgent issues, and then cut the final release (1.0?).
   After that we should probably declare a quiet period and give a deadline. Only critical issues will be addressed in that timeframe, and once the deadline expires the repo would be archived (= read only, no more changes ever).
   Then we import the codebase in go-hardware and carry on with the development.
   This "quiet time" should probably be generous, 6 months at very least, possibly a quarter or two more.

   This clean break would be backwards compatible since we won't be "moving" anything... we'd essentially be starting a new project and encouraging users to change their imports to the new location. And an approach of building something new under the github.com/go-hardware umbrella would give us an ability to work on things like the resource usage stuff in a different repo or module.

   Sounds fine to me, and can't think about a less disruptive approach.
   We should probably be careful for the first go-hardware release or two, to make as painless as possible for users to migrate; they will probably have the expectations about just changing the import paths, which should be honored.

   Just thinking aloud, we can perhaps have some form of LTS releases in go-hardware on which we commit to backport fixes to branches for a given time (e.g. 3 months, 6 months) and declare the first go-hardware release a LTS one, for the sake of making really as smooth as possible the transition for users.

   Meantime, we can plan disruptive changes (e.g. fix API rough edges, deprecating APIs...) and start implementing them after enough slack was given.

   👍React with 👍1Reacted by Jay Pipes
2. sewnie commented on Feb 10, 2024

   

   sewnie

   on Feb 10, 2024

   Contributor

   More actions

   Move the repository instead of making a new one @jaypipes

   https://github.com/jaypipes/ghw/transfer
3. jaypipes commented on Feb 10, 2024

   

   jaypipes

   on Feb 10, 2024

   OwnerAuthor

   More actions

   @apprehensions the problem is the Go import paths... they will all change and break the world anyway.
4. sewnie commented on Feb 10, 2024

   

   sewnie

   on Feb 10, 2024

   Contributor

   More actions

   @jaypipes Move the organization, Create a new repository with the same git commit history, but put a retract call in the go.mod. There have been some go packages that moved import paths and have done something similar AFAIK. I don't have much knowledge of this, but 100% the repository should be moved.
5. jaypipes commented on Feb 10, 2024

   

   jaypipes

   on Feb 10, 2024

   OwnerAuthor

   More actions

   @apprehensions that isn't how the retract directive works or what it is used for. We're going to need users to update the go.mod files to refer to the new location in addition to updating their go code files to import the new location (or use a replace directive in their go.mod files if they don't want to go through the hassle of updating all import lines.
6. sewnie commented on Feb 10, 2024

   

   sewnie

   on Feb 10, 2024

   Contributor

   More actions

   So, it is still possible to just move this repository to the organization?
   It keeps all stars, issues, pull requests and contributors.
7. jaypipes commented on Feb 10, 2024

   

   jaypipes

   on Feb 10, 2024

   OwnerAuthor

   More actions

   @apprehensions I mean, obviously we'd love to do that and be able to keep the stars, history, contributors, etc. However, that is a process that will immediately cause all existing installations of jaypipes/ghw to break because anyone doing a go mod tidy or go mod download that refers to the old github.com/jaypipes/ghw repository will be broken as the transfer is a one-direction thing that doesn't come with any automatic redirect...
8. sewnie commented on Feb 10, 2024

   

   sewnie

   on Feb 10, 2024

   Contributor

   More actions

   https://stackoverflow.com/questions/62243083/how-to-change-go-modules-path
9. ffromani commented on Feb 11, 2024

   

   ffromani

   on Feb 11, 2024

   Collaborator

   More actions

   My 2c: Suggesting the userbase to change their go.mod adding a replace is viable, but IMO is not obviously better than the approach we were evaluating. The reason is we favor the project vs we favor the users.
   I'm afraid there's not yet a obviously better approach, and just to be clear, I'd also love very much to keep all the PRs, issues, contributions and history.
   But if I have to choose, and unfortunately looks the case, I'd take the path which eliminate or reduce the breakage of the userbase.
10. sewnie commented on Feb 11, 2024

    

    sewnie

    on Feb 11, 2024

    Contributor

    More actions

    Are you all sure that it is really not possible to simply add a replace directive in the project itself, update pkgsite to reflect that, and move the repository and only make new releases there? There's obviously a better way...
11. mmlb commented on Nov 14, 2025

    

    mmlb

    on Nov 14, 2025

    Contributor

    More actions

    I've just come across this issue and was a little confused. You can transfer the repo to another org and github will redirect, go is perfectly happy with this situation with or without GOPROXY. Once its in the new repo you can then rename the module to reflect the new org (alternatively, rename to use the domain with a vanity import url and avoid any future issues). When users go to update go will show an error saying the module path has changed and aborts, the user can then decide to update on their own time.
12. mmlb commented on Nov 14, 2025

    

    mmlb

    on Nov 14, 2025

    Contributor

    More actions

    For example I've created https://github.com/mmlb/greet-user that uses https://github.com/mmlb/greet:

    [15:27:15]-[~/t/greet-test]-[manny@zennix]
    cat go.mod
    ─────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────
         │ File: go.mod
    ─────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────
       1 │ module greet-user
       2 │
       3 │ go 1.25.2
       4 │
       5 │ require github.com/mmlb/greet v0.0.0-20251114200353-f25b3b8fb3b2
    ─────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────
    [15:27:19]-[~/t/greet-test]-[manny@zennix]
    go run .
    hello world
    

    After I move to a new org it will still work (not really noticeable from go's POV):

    [15:30:10]-[~/t/greet-test]-[manny@zennix]
    sudo rm -rf ~/.cache/go*
    [15:30:16]-[~/t/greet-test]-[manny@zennix]
    GOPROXY=off GOPRIVATE='*' GONOPROXY='*' GONOSUMDB='*' go run .
    go: downloading github.com/mmlb/greet v0.0.0-20251114200353-f25b3b8fb3b2
    hello world
    

    Now I'll go and rename the module in go.mod and try to update:

    [15:34:58]-[~/t/greet-test]-[manny@zennix]
    GOPRIVATE='*' go get -u
    go: downloading github.com/mmlb/greet v0.0.0-20251114200353-f25b3b8fb3b2
    go: downloading github.com/mmlb/greet v0.0.0-20251114203123-29d0444f8e50
    go: github.com/mmlb/greet@v0.0.0-20251114203123-29d0444f8e50: parsing go.mod:
            module declares its path as: github.com/mmlb42/greet
                    but was required as: github.com/mmlb/greet
            restoring github.com/mmlb/greet@v0.0.0-20251114200353-f25b3b8fb3b2
    

    Unfortunately this only works if bypassing google's go mod proxy with GOPRIVATE='*' otherwise go get -u see's no updates and users stay on old versions. If this project were at v1 you could have probably use a v2 to make noise to advertise the new location.

    This will only work while github.com/jaypipes/ghw is never re-created (otherwise github stops redirecting and users face breakage).