-
Notifications
You must be signed in to change notification settings - Fork 498
Linking to other ua-parser Libraries #22
Comments
LGTM. |
Still unsure why the Ruby Gem couldn't be in the same folder, BTW. |
A few reasons:
|
Happy to include a link to other implementations in the main README. |
It would be better if you convert this repo to organization, seriously!
If I work on a PHP project, it’s a pain to systematically remove or bypass other libraries:
It’s true. There are lots of commits in each folders, and they can break some pull requests, or make forkers confused. I add these:
You have said you haven’t the time to do this. Personally, I'm ready to help in this action, if you want and if you decide to, and create the website :-) Sorry for my bad English... |
@LeoColomb I'd like to make the move but want a clear strategy on how to share the regexp across repos. Eager to hear your proposal and submit it to @elsigh and @dmolsen. |
We've been using the git submodule method of embedding the patterns yaml in https://github.com/toolmantim/user_agent_parser with great success, with Travis testing support too. It simply lives under If the org gets set up I'd be happy to move the ruby gem there (e.g. http://github.com/ua-parser/ruby) |
What bothers me with this strategy is all projects need to actively upgrade everytime there's a change to the YAML. |
Quite often the Ruby library has needed to be updated/refactored to handle YAML updates (just as with any type of software dependency). Being able to lock certain versions of the ruby gem to certain versions of the YAML is quite handy, and if there's ever a need for a minor patch release (for security etc) it's trivial. Unless you want to start branching the YAML repository to ensure you don't make any backwards incompatible changes whilst still updating the patterns, I'd prefer to take on the job of worrying about these things so the user of the gem doesn't have to (but to still providing the option if they want to use a newer, untested YAML file) |
Also, we live in a world of easy forking, so it's very easy for someone to fork the Ruby library, update the git submodule, and then use that instead of the official gem. Travis will even test their gem against the pattern library for them. I can't see any reason why someone would want the Ruby version to be the main ua-parser repository. Maybe someone does, but no-one's said anything yet. So that's the perspective from my side. I'm also completely happy to keep the current setup. |
That doesn't really address my concern. :( |
I'm really not sure of the solution… at least a link in the Readme isn't a bad first step though. |
For the ruby lib? Sure. Lets do this. Mind sending a PR? |
As cool as it'd be to get repos into this one official library it makes sense to keep some separate (e.g. the Ruby gem). Should we at least link to them in the main README?
I think the only other ua-parser related library I've found out there is written in Haskell.
The text was updated successfully, but these errors were encountered: