back to article JFrog to open freebie central repository for Go fans in the new year

Self-proclaimed "Database of DevOps" JFrog is about to fling open the first central repository for Go modules in the form of GoCenter. Originally developed by Google, the open-source language Go, which celebrated its ninth anniversary last month, has seen impressive growth over the years. It hovers in fifth place in Stack …

  1. Justin Clift

    So... trying to replace GitHub?

    > Go lacks a central, public repository for modules.

    No, it really doesn't.

    The default central, public repository for modules is GitHub. Developers are free to place their code in other places too, but GitHub is the generally accepted source. Also happens to be version controlled.

    > Without an immutable source for code, developers have to repackage their modules

    Huh? Is someone getting mixed up with Python?

    > ... and, rightly, eye modules pulled off the 'net with suspicion since the code could easily change without warning.

    How is having your code in JFrog going to be more trustworthy than (the same code) from GitHub?

    1. Deltics
      Holmes

      Re: So... trying to replace GitHub?

      Yes GitHub is version controlled, but it doesn't mandate or enforce a standardised mechanism or convention for a obtaining or specifying a specific Version "X" of Module "Y" without knowing the specific repository in which it is held, the layout of that repository and the particular tagging conventions used by the repository owner to indicate specific versions in the commit history.

      It seems rather more simply that JFrog are trying to establish for Go what nuget, npm and maven et al have established for other languages (and note that GitHub doesn't make those any less useful).

      Having code in nuget, npm and maven doesn't make it more trustworthy, simply more convenient and reliable (*).

      Same rules apply.

      (* reliability in the sense that when two developers say that they use version X of package Y, now they can be sure that they are indeed talking about exactly the same thing in a way that they possibly might not be if they both pulled the code from two difference sources who each had their own idea of which particular revision of that code should be labelled with that version. To that extent you might also consider it **more** trustworthy on those terms even if it does nothing to help assure anyone that "this code works and doesn't contain anything dangerous")

    2. jbaruch

      Re: So... trying to replace GitHub?

      JFrog doesn’t mean to replace GitHub or claim to be the IP source for the modules. The goal of GoCenter is trifold:

      1. Speed up the resolution of modules. Currently, modules are packed on the client (for the most part). The source code is cloned every time the module is requested, packed into an archive and stored on a single computer cache. It could be more efficient: GoCenter caches the archived modules, providing a simple and efficient one file HTTP GET download.

      2. Provide immutable cache. Go modules rely on GitHub tags for versioning. While in general case once a tag is created its content won’t change, there are no guarantees for that. Git allows force-push new code under an existing tag, practically allowing retrieval of different code for the same module request over time. This an anti-pattern in dependency management. GoCenter fixes that by locking the content under a version of a module. You will always retrieve the same module that was first cached, regardless of what happens with the tag in GitHub.

      3. Provide persistency. People delete content from GitHub. That might lead to non-reproducible build. You used ad dependency once, but now, when you run the same go build from a different machine it fails because Go won’t be able to download the sources of the dependency as it was deleted. GoCenter fixes that by caching the modules forever.

      You can find more on the relationship between the module sources in GitHub and GoCenter and on the benefits we provide in our FAQ: https://jfrog.com/gocenter/

  2. Justin Clift

    (continued)

    > JFrog anticipates rapid growth of the library as the community takes advantage of the freebie service, reckoning the repository will soon be home to thousands of modules, including packages for tech such as Kubernetes.

    So, their "modules" are going to be precompiled bits of Go code? Which developers should trust, instead of just compiling the same code themselves. Which Go would compile very quickly anyway.

    Frankly, really not seeing the point. It sounds like JFrog are trying to insert themselves into the Go ecosystem, but haven't really figured out where they could do so usefully.

    1. jbaruch

      Re: (continued)

      Go modules are always sources. The mod archive is just a tar.gz of the source files with metadata about it. This format was developed by Russ Cox (one of the creators of Go) and explained in a series of blog posts: https://research.swtch.com/vgo-intro. The modules are part of Go since 1.11, and you can read more about their structure in the official Go documentation: https://github.com/golang/go/wiki/Modules

      JFrog tries to help the adoption of Go modules by providing a faster and more reliable way to retrieve Go modules (without taking ownership on the modules themselves) as we believe it is the right solution for Go dependency management problem.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019