3 ms·
Tying package management to GitHub seems convenient in the short term, but will be the baggage of the next generation. I cringe hard when I see projects depend
by Hendrikto 4y ago
Tying package management to GitHub seems convenient in the short term, but will be the baggage of the next generation.
I cringe hard when I see projects depending on git repos, without pinning a version or commit.
- staunton 4y agoIt's not actually tied to GitHub. If GitHub died tomorrow, they would easily be able to move on and host the packages somewhere else. There's no way to do this without hosting. Also, there is a way to pin a version or commit. Julia for example always stores the exact commit information for all packages in the "Manifest" file. There are also straightforward ways to demand certain versions and package maintainers have the opportunity to specify compatibility and requirements precisely.
- simiones 4y agoThere will be a mess of dependencies of old projects that depend of projects that have since moved off GitHub, there will be name clashes between GitHub projects and BitBucket projects etc. These ecosystems are very much dependent on GitHub, and if/when anything permanent changes, it will be a mess to move off of it.
- ChrisRackauckas 4y ago> there will be name clashes between GitHub projects and BitBucket projects etc. The package manager requires a canonical URL for the git repo. The location of dependencies doesn't matter, for example Github repos with Bitbucket dependencies work fine. The FastLapack packages lived on BitBucket at one point, and then migrated to Github, and that happened without a hitch to upstream packages like LinearSolve.jl or DifferentialEquations.jl. Also, it takes a one line change to General change a package's from Github to BitBucket. It didn't take me more than 2 minutes when I tried. Did you not have a similar experience? Can you show the PR where you gave it a try? Or is your response just speculation? The package server mirrors the repos, so even if these services went down it would not break the dependency chain (developers wouldn't be able to easily update the packages, but the installations and all would still work). So if tomorrow Github decided to make all of the code private for some odd reason, Julia's package server would continue to serve the current versions.
- simiones 4y agoI was mostly speculating, and thinking more of how Go does Github dependencies. I am happy to hear that Cargo doesn't have the same sort of issues. I really should have looked into it more before commenting, especially since I knew Cargo is actually a well-designed and considered package system.
- staunton 4y agoJust to make sure there are no misunderstandings. ChrisRackauckas was talking about Julia's package manager, (which is called Pkg, if you need to name it, although I would just call it "the package manager"). Cargo is the Rust package manager.
- deleted 4y ago[deleted]
- aabbcc1241 4y agoIf the git repo url is content addressable, using p2p network like ipfs / zeronet / magnet link, then should be easier to move the storage provider to any host as long as it's connected to the p2p network.
- henrydark 4y agoStrictly speaking, hosting like github isn't the only way, an alternative being some peer to peer network like torrents
- ChrisRackauckas 4y agoJulia and Rust all work with using versions tied to git tags. Package management isn't tied to Github but git: packages can live on Gitlab or BitBucket, though they generally don't and that's the choice of package developers. Because of that there are tie-ins to make Github really nice to use, but for example with Julia the only piece that is truly Github based is the fact that the General registry lives in a Github repo (https://github.com/JuliaRegistries/General https://github.com/JuliaRegistries/General), but could easily migrate to another git platform if it needed to.