gplib is the module name; grammar_parser_lib is the project name

The project page for this module spells out the dependencies.

The Grammar Parser Library project also includes a Drush Make file that will download the Libraries module and put the parser files in the proper place.

The Grammar Parser project also describes the setup on its project page and in a README.

There's still something funky going on here. There is no Drupal project called "gplib".

That's correct. The project has a longer name, grammar_parser_lib, but it's module file has the shorter name, gplib. The project is mentioned in #1 above and on this project's page - Grammar Parser Library.

Were you using Drush Make or something similar to download the project?

I found installing coder upgrade pretty tricky

There are three mistakes I made

1. I didn't initially read the requirement to use the latest dev versions of dependencies

2. I was confused by the naming mismatch of gplib vs grammer_parser_lib

3. I didn't understand how to install grammer_parser as a library (place it in sites/all/libraries - don't enable it as a module)

I don't think I was being unduly dim - so maybe an INSTALL file for coder_upgrade would be useful - please see the attached as a starting point

I added a README and a Drush Make file in this commit. Unfortunately, it is a day after the 1.0 release. Hopefully, if others continue to have this problem, they will find this issue.

There are README files in the Grammar Parser and Grammar Parser Library projects, too. And a Drush Make file in the latter as well.

I agree that the install instructions could stand to be a bit more clear. I also understand that since this project relies on other possibly-changing projects (e.g. libraries, gplib) keeping the instructions crystal clear could prove to be a full time job.

In all honesty, this is a really great module.

For the record, I had to do the 'drush make' bit to get it to work.

Thanks for a great module.

This/these module(s) could really use some clearer instructions. I don't understand why it's broken into three modules with two different installation options. I've never seen a module that wasn't a module and should not be enabled in order to enable it. Add the inconsistent project names (gpui, grammar_parser, gplib) to the mix and it's an awful lot of confusion.

Why not package it as a single module? Even developers shouldn't need to spend more than five minutes figuring out how to install a module.

That said, I'm hoping the time spent figuring out how to install this pays off. :)

I just recently had to do another install of this and agree with #9. (And, yes, I'm the same guy from #8.)

Just for the sake of documenting what I did (this time, anyway)....

• 'grammar_parser_lib' is the module name

:-/

• 'grammar_parser' is the library name

o_0

• 'gplib' is the name of the files within the 'grammar_parser_lib' module <--Not all that important. Included for clarity.

So, yeah, in this case it is NOT Grant who is buried in Grant's Tomb.

(It's 'grant_lib'.)

I'm here all week, folks!

If one were to check the closed issues (but I'm not faulting you if you have not or suggesting you should per se), he would find that these questions have been raised previously and answered too. Nonetheless, as repetition is helpful for remembering...

In response to #8-10, there are reasons for all of these things, some better than others. To me, the install instructions are quite clear whether you use drush or not. If you use drush, then the make file does it all. If not, then the make files and README files in this project and its dependent project indicate the projects and library to download, and where to put them.

Why not one module for all of this? Have you ever noticed the Views project includes a Views UI module? Or, core has Fields and Fields UI? Granted, Views UI is in the same project as Views and the parser UI is separate (as touched on next), but the concept is valid.

The grammar parser is pure code. It has no dependencies on Drupal and is justifiably a library. Just like jQuery, and Symfony and the other libraries in D8. If I were to revert this and include the UI code with it, then others would complain (as they have) that they can not run the parser without a Drupal bootstrap.

The rub is that Drupal's project management system only knows of projects with modules. There is no choice to make a library. I may move the parser code off of d.o., say to github or sourceforge. Then it will be just like wysiwyg editor libraries, jQuery, etc.

About the project names not matching the module name. First off, a project != module, so there is no requirement that the names match. Has anyone ever used the content module in the CCK project? There are other examples of this.

How is this so different from installing a WYSIWYG editor?

Solotandem,

I think this is a great module so I'm gonna kinda play devil's advocate here. Just hear me out.....

The fact that the library directory is called 'grammar_parser' and the module directory is called 'grammar_parser_lib' is pretty confusing, no?

Wouldn't it make more sense if those names were reversed so that 'grammar_parser_lib' is the directory that should be placed in the 'libraries' folder (as it contains the word "lib")? And 'grammar_parser' was the folder that goes into the 'modules' directory?

I'd think that would at least stem some (if not most?) of the confusion.

Still a fan,
Aaron

I agree with the point (I struggled with that when the "_lib" module was created), but the parser was around first and it does not deserve to have "_lib" appended to its name any more than jQuery, Symfony, etc. The "_lib" module is just glue to interface with libraries, as you know. It was more of a question what to name the latter when I switched to that format (and I could not think of anything better). Some of the history involves "pressure" to make a 6.x branch of the parser, which i resisted then and now as the parser is not drupal version dependent. That inspired the use of libraries.

It seems the confusion is moot if people use drush make. And given this module is for developers, then it would seem it's about time for everyone to use drush make with it. (I know there are those who work on Windows and drush has been an issue for them, but that is a whole topic to itself.) :)

IMHO, the README is not clear, largely because of the naming conventions and the 'do not install' to install approach.

Even if the README were crystal clear, the only time anyone reads the README is when things don't work, and by that time, they're not happy and prone to make mistakes (or maybe that's just me).

I'd prefer to see a single module that when enabled simply allowed you to configure the location of the actual library or perhaps mandating that it live in .../libraries/... where the shell could access it too without a bootstrap. The module could include a sub-module for the UI. All nicely wrapped up in one module that can be installed the expected way.

Bottom line, I think this is an important bit of code and should be easy-peasy to install.

I appreciate your work very much.

Good to hear your appreciation. Thanks.

When you say "a single module," are you referring to Coder Upgrade, Grammar Parser Lib, and Grammar Parser UI? Or the latter two? Or something else? Are you wanting the Grammar Parser included in this "single module" as well?

Also, the first time you install a WYSIWYG editor, did you do that without reading a README?

This is definitely more confusing than I think it should be and I've raised it here #1351840: We need some documentation in the past.

I've been using Coder for a long while. With most of Drupal it's reasonable to just assume if a dependency is missing to just download it like:

$ drush en coder_upgrade
No release history was found for the requested project (gplib).                                                                                                                                   [warning]
Module coder_upgrade cannot be enabled because it depends on the following modules which could not be found: gplib                                                                                [error]
$ drush dl gplib
No release history was found for the requested project (gplib).                                                                                                                                   [warning]

I'd agree with @Harry though about the goals.

Please don't take offense, but imho the discussion is long on whining and short on substance. As I mentioned in #11, if this module had dependencies of content and views_ui, then you would be in the same situation. As @mgifford writes in #11, the approach of "with most of Drupal it's reasonable to just assume if a dependency is missing to just download it like":

drush dl content
drush dl views_ui

would fail (because a module != project and dependencies are modules but drush downloads projects). Yet I would be willing to bet none of you would be complaining about either of those. You would know to download the CCK and Views projects. Why is this any different?

I think the basic point we're trying to make is that someone with several years experience with Drupal should be able to install any "module" in just a few minutes.

WYSYWIG modules are a good comparison. They too have dependencies on libs. Typically when you install a WYSYWIG module without viewing the README, you'll get warnings that the necessary libs have not been configured. There will always be an admin page where you can go to figure it out.

Similarly, I think it would be a lot easier for people to install GP if they could install a module that might only do one thing, and that is to verify that the lib exists in the proper directory and instructs the user what to do if it doesn't.

Having the lib as a separate module implies that installation of that module satisfies the requirement, but it doesn't. I'd ship the lib with the "wrapper" module. Or, worst case, require a separate download of the lib (like they do with jquery modules, WYSYWIG modules, etc.).

I think making the module simple to install would broaden it's use and help ensure future development of it.

There only appear to be a couple of us sharing this opinion, so if you really just think we're whining and there's no substance to it, please disregard :)

Frankly this is a bigger issue than just what the Coder maintainers want to do too. As someone who has been actively pushing module developers to use Coder I see this as being an important way of ensuring that the code is as uniform as possible. With a rapidly changing Core & 14k contrib modules this is a real challenge. Without active use of a module like Coder to review, improve & upgrade modules then it's always going to be a bit of a wild west in the Drupal world.

The Drupal community needs Coder to be easy to setup & install. It needs maintainers who are also able to listen & effectively respond to the community too. @solotandem labeling folks as whiners who want to use this module just isn't very helpful.

I do love @webchick's video from DrupalCon Denver - http://denver2012.drupal.org/program/sessions/drupal-community-where-are...

She didn't say RTFM.

There are only 4353 reported installs of Coder from 145,466 downloads. I don't know if we can tell how many folks have installed Coder Upgrade but it's probably in the hundreds. Well, actually we can easily figure this out as Grammar Parser Library has 517 installs & Grammar Parser has 186.

So we can be confident that less that only 4% of the Coder population bothers with Coder Upgrade.

Maybe it's because it's a pain to install and the documentation needs work....

Hear hear re: mgifford's comments. Seriously, I've been trying to get this module to work for at least an hour at this point and am at the point of giving up. The documentation is badly written and contradictory (Especially with regards to versions, using Drush make, etc.); the whole "use Grammar Parser as a library! No, wait! Use it as a module! No, wait! USE IT AS A LIBRARY! BUT THE OLD VERSION!" bit is really tiring.

To then come to this issue with an unhelpful maintainer who simply waves his hand and tells people to go GTFOARTFM (Which, let's not mince words -- the manual is *nonsense*) makes me more than a little angry deep down inside.

Sorry folks,

This is truly ridiculous. I have been a coder for a VERY long time. This is one of the most confusing install process I have ever seen... and mostly because of terminology. Some of it is unavoidable (no control over one of the Library modules!)

NO it is not helpful to tell people to read the drush makefiles. I don't use drush. Don't tell me to install drush. That will just tell me you don't really want me to use your module. Is this module dependent on drush? I sure hope not.

I was following instructions and downloaded, then erased grammar_parser_lib, because grammar_parser says IT is the real library and the *_lib module is just an interface to it. Now (on this page) I read that I actually need both.

SO... what appears to work is as follows. This could be in the README for Coder:

To use Coder Upgrade, you will need several required modules and a library. The names are quite confusing so be careful following these instructions. (If you use drush, you don't need to understand all this.)

1) http://drupal.org/project/libraries (the Libraries module), should be installed in sites\all\modules (as a module)

2) http://drupal.org/project/grammar_parser_lib (the Grammar Parser Lib module), should be installed in sites\all\modules (as a module)

3) http://drupal.org/project/grammar_parser (the Grammer Parser, a mixed-use project), should be copied into sites\all\libraries (as a library)

Easy as 1-2-3 :)

Final note, now that I have it running:

To run Coder Code Reviews, you need PHP_CodeSniffer.

A non-obvious setup for this is how to activate that package when developing for Drupal under XAMPP (I'm doing this on Windows but the principle may apply more widely.)

It's pretty simple, but most if not all the documentation out there (today) is incorrect.

1) Open command prompt
2) switch to drive letter of your XAMPP folder, then CD \XAMPP\PHP (assuming your XAMPP is in the root.)
3) do the following to see if PHP_CodeSniffer is already installed:

pear list

4) Assuming it is not yet installed, do this:

pear install PHP_CodeSniffer

#21 helped me to remember how the heck to install this again. Granted it is 1:30am on a Friday night (Saturday morning actually!) and I'm not exactly on my toes right now.

However, I am ALWAYS confused by this install process as I use coder_upgrade and api module which both depend on these three projects. I don't install either of those things very often because once I have a site set up I keep using it for a long time and only periodically have to create a new site.

I think I've been around for long enough to have a decent amount of experience in using Drupal (I've been using it since version 4.7, for 6 and 1/2 years), but this process always catches me out. It's really painful to have to stop in the middle of doing something which should be so natural and flowing to have to jump through these hoops.

I understand that the grammar parser module evolved into the grammar parser library and that's how it is still called grammar_parser vs the new module called grammar_parser_lib which is glue code that interfaces with the library (I can see how at the time of the split the "Grammar Parser Library" could have been seen as, "the module that you use to interface with the grammar_parser library"), but ultimately this is incredibly confusing and the README doesn't do enough to help. Also, the shortened module name "gplib" just compounds. Why do people even do this? What was wrong with using grammar_parser_lib? Were you worried about long function names?

I'm re-opening this ticket so the docs can be improved to be easier to understand like in #22. I'm not hopeful of actually fixing the root problem as it would mean some project namespace juggling but the least we can do is make the READMEs and project pages clearer.

I'm in full agreement with the many people that have posted here. But I also see that many people have written several paragraphs of complaints, but no one has yet posted a patch, or even list of specific ways to improve the README. Perhaps re-focusing our energies into action might do more to help move things forward.

I too was banging my head against the wall trying to get this to install. One of the difficulties in such a situation is that you know it's not working, and have no easy systematic way to track down the problem. The problem I had in the end was that I had installed a version 2.x of the grammar_parser library rather than the requested 1.x version. The error message which I had read many times before I realised it held the key eventually led me to the correct installation;

Install version 7.x-1.x of the Grammar Parser library code (from here) in a libraries directory such as "sites/all/libraries."

Great! Thanks. My mistake. I guess the thing in my thinking was that I had installed the Grammar Parser library code, but I didn't realise I had installed the wrong version, nor that it was so critical to use that version. My normal habit is to take whatever the latest recommended version of the module is.

It would be even better if you could detect when someone has made the error I have and the message was even more explicit, e.g.:

It looks to me like you've installed version 7.x-2.x of the Grammar Parser library code, but you need to Install version 7.x-1.x of the Grammar Parser library code (from here) in a libraries directory such as "sites/all/libraries."

If this is not possible, maybe just make it clear that the version is critical, e.g.:

Install version 7.x-1.x of the Grammar Parser library code (from here) in a libraries directory such as "sites/all/libraries.". Note that if you have installed a different version, e.g. 7.x-2.x, then it will not work.

Be sure to look at the drush makefile for coder upgrade. It will download all required packages for you as well as save time and headaches --> https://drupal.org/node/1413398

So, anyone coming from the future still having problems with this (it's taken me several hours to get it working, having tried every combination of Libraries, Grammar Parser, and Grammar Parser Library available for download, and always getting errors about Grammar Parser not being installed). The drush makefile in grammar_parser_lib does seem to work. The drush make file pulls in a version of libraries that is no longer listed for download (2.0); I guess exact versions are really mandatory, though it is not clear from the documentation which specific versions (docs indicate Libraries 2.x, but 2.2 and 2.x-dev result in a dependency error about Grammar Parser being unavailable and coder_upgrade is non-functional).

I did the following to finally make it work, after significant frustration (I have never used drush make, and all of the docs I found weren't very clear about how it should be used):

From within my drupal site root, I ran:

$ drush make --no-core sites/all/modules/grammar_parser_lib/grammar_parser_lib.make

After this, coder_upgrade works (and is awesome). But, wow, that installation is ornery.

I know the Drush make installation method is what is recommended in the docs, but drush make is not particularly obvious in its usage (like where it should be run from and the --no-core option), at least, it was not obvious to me.