On Thu, 13 Oct 2016 04:36:27 -0700 (PDT) Thomas Modeneis <thomas.moden...@gmail.com> wrote:
> > Does "NPM installs the target module" mean it's pulling and/or > > updating > its sources to a VCS? > > NPM decided that releases are part of a module. This module should be > release explicitly by the team/developer in charge for the module, > and the module version is consequently bumped after. > So developers that just want to use a module, do not have to worry > where that project VCS is, if stills online or not, if exists or not. > All this factors are mitigated and handled by NPM, due to its > release/usage mechanism. That's a strange point you're making here: NPM might not be online just like the project's repo might be [1]. If we recall the recent left-pad debacle, it becames apparent that if you really think about the future of your software and wants to make its lifecycle not depend on the availablilty of external resources, you have to vendor your dependencies. So we again arrived at square one [2]. [...] > In the other hand, Go decided (or the absence of a early stage design > decision caused this) that releases are linked to explicit commits, > so VCS was added to equation to mitigate the problem I think you're wrong on this: you put extra meaning into what `go get` does. `go get` is merely able to fetch code from several VCS systems (and knows about the specific of several popular hosting solutions). It explicitly knows nothing / does not care about which "version" of the software it manages to download. You're not at all oblidged to use `go get` (for instance, I, for one, almost never touch it): instead, you're free to explicitly pick whatever versions of the 3rd-party libraries you want, and do this in a way you want it. For instance, I personally use Git subtree merging to vendor my dependencies, and hence I explicitly decide which versions I merge (and hence depend on). > + enabling people to use external projects into their Go modules... > So several projects have been created to address the issue, like > godeps, gm, glide. But (correct me if I'm wrong) there is no central > repository for releases in Go -> > http://stackoverflow.com/questions/38595887/does-golang-have-a-central-repository-for-the-downloaded-third-party-packages Yes, there's no central package repository. Personally, I have no opinion on this. On the one hand, it might be convenient to have. But that's only if you're "infected" with an NMP-ish approach to working with packages. The problem is that proponents of this approach implicitly assume it's the best thing to have, but this is arguable (i.e. that would be "one size fits all", and folks at Google explicitly abstrained from instilling it on the community because they would not use this approach anyway). 1. https://www.reddit.com/r/rust/comments/35kf6h/now_that_cratesio_is_down/ 2. https://golang.org/doc/faq#get_version -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
