4 ms·

Unless you need to run a bundle install (or npm install, or whatever) and have github urls in your Gemfile.

by pbiggar 14y ago

robryan 14y ago
Does Bundler allow for multiple gem sources to be specified (on a gem by gem basis)?
- pbiggar 14y ago
  I'm not 100% positive on the specifics, but I've never seen it used. I suspect its not possible. (context: I make https://circleci.com https://circleci.com - a continuous integration company for web apps, often Rails. We occasionally get support requests that allow/ask us to look at Gemfiles, so I've seen an above average number of Gemfiles. However, I more often see the stdout of the `bundle install` command, which shows GitHub being accessed).
- skateinmars 14y ago
  Yes, you can specify a git repo in your Gemfile (and optional tags/branches) : gem "rails", :github => "rails/rails", :tag => 'v3.2.11' You can also specify multiple gem sources (http://gembundler.com/v1.2/gemfile.html http://gembundler.com/v1.2/gemfile.html), but usually only rubygems.org is used unless you need a private geù repository.
  - robryan 14y ago
    Yeah the question is, can you specify to grab rails from github with a fallback if it is not up? So the same system it seems to be using with multiple gem sources but on a gem by gem basis like you would do with a github repo.
lmm 14y ago
Yeah, don't do that. As a scala/maven guy it kills me to see all these package managers making the same mistakes we already solved, over and over again.
- pbiggar 14y ago
  Why not?
  - lmm 14y ago
    Because it's tying you to an unreliable third-party service, and there's no way to mitigate it. Artifact dependencies really shouldn't be in the same place as source, they fulfil different roles. What you want is a dedicated repository format. Libraries can still be hosted by whoever maintains them on their own repository (which can be their own piece of software as long as it follows the standards), or in the community central repository. But either way, if you depend on those libraries and want to lower your risks, it's trivial to set up a local mirror and make sure all your third party dependencies come in via this mirror. That way if their repository goes down temporarily or permanently it's no problem, and you ensure your builds remain reproducible. The most infuriating part is, the software to do this already exists. If you want to start a new language, great. But please, use maven; otherwise you are doomed to re-invent it, poorly.
    - deleted 14y ago
      [deleted]
    - pbiggar 14y ago
      I disagree completely and vehemently. Because it's tying you to an unreliable third-party service, and there's no way to mitigate it. > Sure GitHub has been having some problems recently, but they are all-in-all massively reliable. > Artifact dependencies really shouldn't be in the same place as source, they fulfil different roles. Seems like a dogmatic point - why is this advantageous? More importantly, there is a reason people do this - they want a zero-effort way to use certain branches, tags, etc. They want source. >What you want is a dedicated repository format. Again, seems dogmatic. What advantage does one format have over the other. > in the community central repository and now we have single point of failure again, but I also have to wait for someone to either upload, or set up an automated solution to upload, the version I want. There's a reason people use the source for this. > it's trivial to set up a local mirror and make sure all your third party dependencies come in via this mirror Nightmare. We actually do do this - we maintain a nexus instance on EC2. Its a fairly awful experience. We wouldn't use it if there was a way in leiningen to use git, and if maven wasn't so slow at getting dependencies. > That way if their repository goes down temporarily or permanently it's no problem, and you ensure your builds remain reproducible. Definitely a real problem. But there are real tradeoffs here. > The most infuriating part is, the software to do this already exists. If you want to start a new language, great. But please, use maven; otherwise you are doomed to re-invent it, poorly. I use maven on a daily basis. Its not great to be honest, and comes with a massive amount of baggage, including the SNAPSHOT stuff which is awful, and a lot of things tied to java. Rubygems are a significantly better experience, are a lot more usable, and have some really good features like being able to use Github links :)

Unless you need to run a bundle install (or npm install, or whatever) and have github urls in your Gemfile.

by pbiggar 14y ago

Unless you need to run a bundle install (or npm install, or whatever) and have github urls in your Gemfile.

robryan 14y ago

Does Bundler allow for multiple gem sources to be specified (on a gem by gem basis)?

pbiggar 14y ago
I'm not 100% positive on the specifics, but I've never seen it used. I suspect its not possible. (context: I make https://circleci.com https://circleci.com - a continuous integration company for web apps, often Rails. We occasionally get support requests that allow/ask us to look at Gemfiles, so I've seen an above average number of Gemfiles. However, I more often see the stdout of the `bundle install` command, which shows GitHub being accessed).
skateinmars 14y ago
Yes, you can specify a git repo in your Gemfile (and optional tags/branches) : gem "rails", :github => "rails/rails", :tag => 'v3.2.11' You can also specify multiple gem sources (http://gembundler.com/v1.2/gemfile.html http://gembundler.com/v1.2/gemfile.html), but usually only rubygems.org is used unless you need a private geù repository.
- robryan 14y ago
  Yeah the question is, can you specify to grab rails from github with a fallback if it is not up? So the same system it seems to be using with multiple gem sources but on a gem by gem basis like you would do with a github repo.

lmm 14y ago

Yeah, don't do that. As a scala/maven guy it kills me to see all these package managers making the same mistakes we already solved, over and over again.

pbiggar 14y ago
Why not?
- lmm 14y ago
  Because it's tying you to an unreliable third-party service, and there's no way to mitigate it. Artifact dependencies really shouldn't be in the same place as source, they fulfil different roles. What you want is a dedicated repository format. Libraries can still be hosted by whoever maintains them on their own repository (which can be their own piece of software as long as it follows the standards), or in the community central repository. But either way, if you depend on those libraries and want to lower your risks, it's trivial to set up a local mirror and make sure all your third party dependencies come in via this mirror. That way if their repository goes down temporarily or permanently it's no problem, and you ensure your builds remain reproducible. The most infuriating part is, the software to do this already exists. If you want to start a new language, great. But please, use maven; otherwise you are doomed to re-invent it, poorly.
  - deleted 14y ago
    [deleted]
  - pbiggar 14y ago
    I disagree completely and vehemently. Because it's tying you to an unreliable third-party service, and there's no way to mitigate it. > Sure GitHub has been having some problems recently, but they are all-in-all massively reliable. > Artifact dependencies really shouldn't be in the same place as source, they fulfil different roles. Seems like a dogmatic point - why is this advantageous? More importantly, there is a reason people do this - they want a zero-effort way to use certain branches, tags, etc. They want source. >What you want is a dedicated repository format. Again, seems dogmatic. What advantage does one format have over the other. > in the community central repository and now we have single point of failure again, but I also have to wait for someone to either upload, or set up an automated solution to upload, the version I want. There's a reason people use the source for this. > it's trivial to set up a local mirror and make sure all your third party dependencies come in via this mirror Nightmare. We actually do do this - we maintain a nexus instance on EC2. Its a fairly awful experience. We wouldn't use it if there was a way in leiningen to use git, and if maven wasn't so slow at getting dependencies. > That way if their repository goes down temporarily or permanently it's no problem, and you ensure your builds remain reproducible. Definitely a real problem. But there are real tradeoffs here. > The most infuriating part is, the software to do this already exists. If you want to start a new language, great. But please, use maven; otherwise you are doomed to re-invent it, poorly. I use maven on a daily basis. Its not great to be honest, and comes with a massive amount of baggage, including the SNAPSHOT stuff which is awful, and a lot of things tied to java. Rubygems are a significantly better experience, are a lot more usable, and have some really good features like being able to use Github links :)