31–40 of 98 posts
Earlier quoted context omitted.
They still allow you to deploy you just have to explicitly set a variable in the deploy command so they know you are aware whats going on
Is this safe if you haven't changed any gems since the last deploy? I have a bugfix that I would like to deploy...
This should also be a reminder to everyone that you shouldn't be reliant on a single point of failure for your deploys. It's something that we in the Python community have already encountered (and hopefully learned from) due to the historical unreliability of our equivalent package repo, PyPI. Have an internal repo that's accessible by your deploy servers, which in turn locally caches anything that you might have pre…
> It's something that we in the Python community have already learned due to the historical unreliability of our equivalent package repo, PyPI. learned sounds a touch condescending to me for some reason. The python community has certainly run into it, but (anecdote time) in my experience people still often rely on pypi for their deploys (but use the --mirrors option to pip). Encountered may be more appropriate.
Earlier quoted context omitted.
Indeed. I presume this is why Perl's package repository CPAN is actually a network of repositories ("Comprehensive Perl Archive Network"); Wikipedia says CPAN "is mirrored worldwide at more than 200 locations." Does anyone know why rubygems does not work this way? I had always just assumed it did (due to the historical intertwining of Ruby and Perl communities).
The central architecture of rubygems allows you to publish and yank gems within minutes. CPAN takes some hours (and deletion may not be controlled). Personally I'm a big fan of the CPAN approach as it is fairly simply. Just mirror via FTP. It's a nobrainer to setup and run a mirror. That said, CPAN's master (PAUSE.cpan.org) is a SPOF as well. What I like is that not a single party is responsible for paying server bil…
Earlier quoted context omitted.
It is possible for the publisher to sign the gems [1], but it's not common. If rubygems.org is keeping fingerprints of each gem, then it still isn't sufficient, since those could have been compromised as well. If there's no other trustworthy source of fingerprints, then maybe we need to crowdsource it. Built a tool that will md5sum all the .gem files in your local cache directory, so that we can look for any files th…
Sounds like a good reason to switch to "everything must be signed"
Earlier quoted context omitted.
> It's something that we in the Python community have already learned due to the historical unreliability of our equivalent package repo, PyPI. learned sounds a touch condescending to me for some reason. The python community has certainly run into it, but (anecdote time) in my experience people still often rely on pypi for their deploys (but use the --mirrors option to pip). Encountered may be more appropriate.
I think you are being oversensitive about a tiny difference of wording, maybe due to some prior history with the Python community?
Thanks for the perspective at any rate. Maybe too much coffee for me this morning? :)
This should also be a reminder to everyone that you shouldn't be reliant on a single point of failure for your deploys. It's something that we in the Python community have already encountered (and hopefully learned from) due to the historical unreliability of our equivalent package repo, PyPI. Have an internal repo that's accessible by your deploy servers, which in turn locally caches anything that you might have pre…
> It's something that we in the Python community have already learned due to the historical unreliability of our equivalent package repo, PyPI. learned sounds a touch condescending to me for some reason. The python community has certainly run into it, but (anecdote time) in my experience people still often rely on pypi for their deploys (but use the --mirrors option to pip). Encountered may be more appropriate.
A tangent, but I always thought "YAML" was pronounced /'jæm.ḷ/, however the post's use of "an YAML" suggests it's actually pronounced /waɪ.eɪ.ɛm.ɛl/. Weird.
A tangent, but I always thought "YAML" was pronounced /'jæm.ḷ/, however the post's use of "an YAML" suggests it's actually pronounced /waɪ.eɪ.ɛm.ɛl/. Weird.