Linking to other ua-parser Libraries about ua-parser HOT 14 CLOSED

LGTM.

from ua-parser.

Still unsure why the Ruby Gem couldn't be in the same folder, BTW.

from ua-parser.

A few reasons:

• it's the Right Way to do it - small, composable libraries (and repos) beat large ones with undefined dependencies every time.
• Travis won't allow multiple-languages per repo
• I want it to be simple for people to be able to fork and contribute w/o worrying about breaking all the languages

from ua-parser.

Your second point seems a valid one. #1and #3 are red herrings, however.

That said, I'm myself in favor of creating an organization and
splitting the repo up, just haven't had the time to look into it nor
to discuss naming with @elsigh.

from ua-parser.

Happy to include a link to other implementations in the main README.

from ua-parser.

It would be better if you convert this repo to organization, seriously!
All reasons evoked by @toolmantim are good:

it's the Right Way to do it - small, composable libraries (and repos) beat large ones with undefined dependencies

If I work on a PHP project, it’s a pain to systematically remove or bypass other libraries:

• It may corrupt the project
• The repo will not appear like an only PHP one

I want it to be simple for people to be able to fork and contribute w/o worrying about breaking all the languages

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:

• It’s not really possible to import with submodules because of first point.
• All members could follow activities on their libraries more simply.
• If you turn it on organization, you will be able to create a website, like H5BP Site, and why not a tool to download a single library with the YAML file included.

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...

from ua-parser.

@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.

from ua-parser.

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 vendor, and the build process only copies the required YAML file, not the entire ua-parser repository. I'd imagine the other libraries could/would do something similar?

If the org gets set up I'd be happy to move the ruby gem there (e.g. http://github.com/ua-parser/ruby)

from ua-parser.

What bothers me with this strategy is all projects need to actively upgrade everytime there's a change to the YAML.

from ua-parser.

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)

from ua-parser.

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.

from ua-parser.

That doesn't really address my concern. :(

from ua-parser.

I'm really not sure of the solution… at least a link in the Readme isn't a bad first step though.

from ua-parser.

For the ruby lib? Sure. Lets do this. Mind sending a PR?

from ua-parser.