You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be convenient for us to have some way to share closed-source artifacts, specially in this project where there is a myriad of gems with dependencies between them. Also, the typical way of telling bundler to download and build the gem from GitHub is fine for applications or while in development, but it's not a good long-term solution when it comes to gem distribution, mainly because all gems should be specified in the .gemspec using specific versions.
Regarding npm packages, the idea is similar. We think the best solution would be to move all static assets to npm packages, as that would resolve all the problems associated with webpacker, and would also enable other kinds of applications to reuse the same assets.
Needless to say, setting up a private gem/npm server would benefit other projects as well.
I did a brief examination of some free & paid options that I've come across. Perhaps some of you have some experience with them? We can start discussing what choice is preferrable. Obviously a paid service is much easier to set up and requires no maintenance, but at the same time, provided the free options are good and solid enough (which they seem to be), setting up a small server for both npm & gems could also be worth the effort. A few of them also provide docker images, which would make deployment quite easy and painless.
Free
Gem in a Box: all-in-one solution to host/push gems.
Gemstash: can act as a cache for rubygems.org and also store private gems.
Gemirro: also provides easy mirroring and private gems hosting.
Can't we just install gems directly from Github? Is that bad practice?
No, that's perfectly fine and not a bad practice, but that only applies to regular applications that depend on the Gemfile and Gemfile.lock to load the exact versions of the dependencies you'll be using in all the environments where the app runs. For gems it's a bit different because, although you also have a Gemfile that can point to GitHub, that's only useful while developing the gem. The dependencies that the gem command worries about are declared in the .gemspec file, and there you can't specify git sources, only specific gem names and range of versions.
If anyone knows of another way of doing this that does not involve setting up a server or duplicating the dependencies in both the gem & the application, please share it!
It would be convenient for us to have some way to share closed-source artifacts, specially in this project where there is a myriad of gems with dependencies between them. Also, the typical way of telling
bundler
to download and build the gem from GitHub is fine for applications or while in development, but it's not a good long-term solution when it comes to gem distribution, mainly because all gems should be specified in the.gemspec
using specific versions.Regarding npm packages, the idea is similar. We think the best solution would be to move all static assets to npm packages, as that would resolve all the problems associated with webpacker, and would also enable other kinds of applications to reuse the same assets.
Needless to say, setting up a private gem/npm server would benefit other projects as well.
I did a brief examination of some free & paid options that I've come across. Perhaps some of you have some experience with them? We can start discussing what choice is preferrable. Obviously a paid service is much easier to set up and requires no maintenance, but at the same time, provided the free options are good and solid enough (which they seem to be), setting up a small server for both npm & gems could also be worth the effort. A few of them also provide docker images, which would make deployment quite easy and painless.
Free
Paid services
Make a comment if you know of any other provider or mechanism to store dependencies.
The text was updated successfully, but these errors were encountered: