Currently I am writing a Ruby on Rails application, and I am using Gems, however sometimes I feel that Gems are not as flexible as I want them to be. To make them more flexible. Should I
Fork them on github, and customize it, but this still present the challenging of managing everything.
or
Strip and merge the code of the gem to the main application? This will allow further customization of the gem. This would be for situations where a Gem require another Gem's functionality.
or is there a better way of doing this?
Thanks
B
Choice A is the better answer for a number of reasons.
You get to merge in security updates, enhancements, and bug fixes easily.
Your changes may get merged into the core--in fact, consider if you could implement them in such a way as they live alongside the core functionality as options. If this happens, you have the ultimate win--nothing to maintain, and you can retire your fork.
Others can benefit from your changes.
Your project's footprint is kept smaller and focused by keeping the gem code isolated.
You'll have something to add to your Github "resume."
If its some kind if not so popular gem or "bicycle" from some previous studio or developer who started project(in my case).
I prefer deprecate this gem's and move code into project,
for example they have c***la-deploy - it's just wrapper to Capistrano 2 with own methods))) - I just delete it and rewrite on last Capistrano 3
Than that have own "CMS" c***la-cms where they wrap standard form_for or simple_form with name "twitter_form_for" ? - fist of all I start try to find gem who use this name, and than find in dependency gem's ...
Its take a lot of time for new developer involve in project - better move to standard rails methods/heplers
But anyway i understand for a what this studio do that - its just vendor lock and for client more hard to move out from them to another developers.
For example for startup its bad to use a lot of dependencies and if it's just simple website - dose not matter.
Related
We're using rack-test for our Cucumber specs. We've been trying to migrate over to Ruby 3 for a while now and the current issue is that the Cucumber tests crash due to rack-test using both keyword/positional args in their internal methods.
I'm up for patching it myself, but seeing how little activity there is on the repo (including PRs open for weeks/months) I fear that I'd do the work and there would be nobody to patch it.
The only alternatives I see are:
Do the work and pray there will be someone to review/merge the changes
Patch it locally & use the patched version locally from now on (yuck)
Find an alternative solution for rack-test
The last solution seems the best IMO. So, are there any alternatives?
As with all open source software, you have a few options:
Keep using the old software version (i.e. don't use ruby v3.0.0).
Hope that someone else updates the dependencies for you.
Do the update yourself.
Stop using the library.
At the moment, option 1 is totally viable; ruby 2.7 is still actively maintained, and support will probably continue until 2023-03-31. You could do this, simply hoping that option 2 becomes available soon.
The standard practice for option 3 is:
Fork the project, and make the fixes.
Open a pull request to the main repo with your fixes. Hopefully it gets merged.
In the meantime, if you need to be unblocked, reference your forked repo in other projects.
This is clearly more effort, but I wouldn't call it a "yuck" solution; not unless your changes are drastic/introduce compatibility issues with the main project, and the two branches diverge.
As for option 4, as with virtually any library replacement, there's always going to be some trade-off between compatibility/features, but clearly other testing frameworks do exist. It depends how you are actually using it. Your mileage may vary.
In summary, I can't really give an objective answer to such a subjective question, but my advice at the moment would be: If you have time/skill/motivation to update to ruby 3 right now, then fork the dependency and update it. (It's probably not a massive change needed!).
But if you lack the time/skill/motivation to do this, then just stick with ruby 2.7 for now.
I am new to Ruby and I have written a small app, that consists of around 50 .rb files and 6 folders. The purpose of app is to be an SDK for Ruby users, to interact with my API. It also uses few gems. Now I want to release this app for specific users, but looking at the internet for the solution really confused me (may be just because I'm new to it) and MOST of the posts found were for Rails
Being through several posts, what I find to be reasonable is to make a gem out of it and publish this gem at rubygems.org. (but this also makes it fully public)
Question:
Is this the correct approach in my specific scenario?
How can I manage the dependencies? (This part is very confusing, I will need more guidelines on this)
How to limit audience? (I have personal git server, would this be of any help)
Other Info:
App is developed in Ruby version 2.1.8, It makes http Get/Post requests using TLS, and is NOT a Rails or web app
I have been through several SO posts like THIS, THIS etc. But I couldn't understand it for my case.
I created a project in Jetbrains' IDE, called RubyMine. My project doesn't have bin folder, etc. but only my own folders and .rb files. And most of the solutions also talk about bin.
Any help will be appreciated.
Gemfury is probably what you're looking for. You'll package your library as a gem the same way as if you were going to publish it publicly on RubyGems, but Gemfury lets you restrict access to it to only the people you want to allow.
My Rails site uses a certain gem which is really not very good. Every time I need to do something new I end up having to spend as much time adding features to the gem as I do adding code to the actual Rails project. But I don't mind, and I have my Gemfile set up to point to my GitHub fork of the gem (I tried submitting PRs, but the maintainer seems to have stepped down).
The problem is that I really haven't found a sane way of testing new things I add to the gem. It'd be especially nice to test it within rails c, but the only ways I can think of doing that are a) Changing ~/.rvm/gems/.../foo.rb, which doesn't seem right or b) Bumping the version, pushing to Github, and running bundle up, which in addition to being time-consuming is obviously a disaster since I don't know for sure whether the commits I make are right or not.
I'd even be perfectly happy with a standard irb. But various permutations of require lib/foo from within the gem's directory don't work.
So what's the best practice here?
If you are using a gem and working on it at the same time, the best way is to use Bundler and provide a local path:
gem 'my_bad_gem', path: '../my_bad_gem/'
This will look for the gem under the given (relative in this case) path. Another option is to use local git repositories (see http://bundler.io/v1.3/git.html).
Is there a tool for creating Ruby gem which automatically generate not only project file structure, but also tests file structure (with default ruby assert tests or rspec)?
You may want to take a look at hoe, which allows you to write your own project templates in erb, amongst other goodies. See http://docs.seattlerb.org/hoe/
Personally I have found, despite looking for something like this initially, that bundle gem <gemname> and a quick reference to an earlier project is not all that much work in practice, considering the number of gems I have written (about 7, though only one is published). Boris Stitnicky's comment rings true for me as well - understanding why a particular structure works, and building it from scratch at least a couple of times is worth the time invested in gaining Ruby knowledge.
However, if my day job project involved creating many in-house gems, I'd probably be using hoe, or a similar tool to get them started consistently.
Me and my team are starting to build up a few re-usable scripts. They're re-usable within our org only as they work with proprietry apps and our particular server environment. So not really suitable for rubyforge or github, etc.
My question is, what is the best practice for ensuring we're all using the latest and greatest scripts across all users? We pretty much run these scripts on one server, but may need to expand to others.
Should we bundle them into gem(s) and start a private gem server?
Or something simpler like a common, shareable lib directory. Perhaps with a script to download/update from our SCM?
Other ideas?
Thanks....
This depends on some factors, like how many people want to change the code (only your team, or someone else too), or how much money you have for this?
Personally I'd create a build+gem server, where you can upload the scripts using some versioning system (like git or svn, depends on how many people are working on the project), and then create a cron job, that would automatically genereate the gems from the sources at generic intervals and store them as different versions. This way you can be sure that you always have an authorative server that stores your applications gems, and you can always get an earlier version if something breaks. Your script might create separate gem version names, like "appserv-edge" or "appserv-stable"
You might also want to check out github's closed source options too, if you have the money to afford that. I don't know however whether they have gem building and hosting facilities for non open-source programs.
I've created a private gemserver and it's dead easy. The only tricky bit is deciding how you want your users to upload gems. Personally, I just use a PHP upload form, and have it check to make sure that it's not masking any existing gems.
At my office we're using a bit of a hybrid approach for some of our shared scripts and libs. We do bundle them all in to a gem, but rather than using a gem server we keep them in source control, and then build the gem (using newgem) and install it locally as necessary.
The downside of this approach is that it takes two commands instead of one to install the gem, but this is largely mitigated in qa and production environments, since we use Capistrano for deployment.
The upsides are that it's dead simple, and in development there is a very short edit/build/deploy cycle if you're working with something that requires changes to the gem. I'm currently pulling a lot of common functionality in to the shared gem, so I'm really appreciating that aspect.