Support the new dev info strings

I've been digging around with hacked on a big code base. I think this issue might be the reason why several projects are providing errors because they aren't able to be downloaded. However, using wget or curl seems to pull in the files just fine.

Has this issue caused issues for others in a similar way?

At this point, I'm seeing other people having problems downloading projects in the other support forums as well so I think it makes sense to flag this as a bug.

+1
same issue here, hacked module does't check modules if the version contains diff number to another version
example: module_name-7.x-2.0-beta4+123-dev

I haven't found any specific documentation about the new dev strings, but I think the way it works is the following:

A module has a dev release (7.x-2.x-dev), but to track which dev version it is, you actually want to track the commit hash. So, what is done is to actually track the most recent release hash/tag (7.x-2.0-beta5) and count the number of commits past that point. Thus, getting 7.x-2.x => 7.x-2.0-beta5+13-dev (baseAPI + "-" + latest release/tag + "number of commits" + "-dev").

Still not 100% sure how to address this in the code, but I think it might be predicated on the ability to support git. #1074536: Git clone support

The steps would be:

1. Get the release tag from the dev info string.
2. Get the number of commits past it from the dev info string, call it "N".
3. Determine the commit ID for the Nth commit past the release tag.
4. Do whatever Drush make does to download the module at a specific commit hash.

Step 3 seems like the tricky part. It's necessary to get this sort of info from git.drupal.org:

• git log --oneline --no-abbrev-commit --reverse TAG..HEAD | head -N | tail -1 | cut -d" " -f1

The patch in #1074536: Git clone support just might do the trick if Git Deploy is installed and the module is a Git working tree, but that's probably only true if the module directory is a clone of the upstream project, not a flat git repository for the whole docroot. Anyway, seems like a good place to start.

Actually, the shell script over at #1863504: Compare dev version against git looks more like what we want, but it's not PHP. Perhaps we could take that idea, and produce a patch from it adding another option to the control structure:

        // Find an item that this project includes:
        if (hacked_cvs_enabled()) {
          foreach ($project['includes'] as $name => $title) {
            if (is_dir(drupal_get_path($project['project_type'], $name) . '/CVS')) {
              $this->remote_files_downloader = new hackedProjectWebCVSDownloader($this, drupal_get_filename($project['project_type'], $name));
              break;
            }
          }
        }

So we could turn this into a switch statement with three (3) options:

• hacked_cvs_enabled()
• hacked_git_enabled()
• hacked_dev_version()

The last one of those would be the new one.

+1
same issue here.
My example is Hacked! itself: hacked-7.x-2.0-beta5+13-dev ;)

Still have issue with this.

I have attached a patch for this which is a simple change, but whether you think it's a fix or not depends on your point of view.

The patch splits the version number up and removes the -dev part when the project object is created and therefore will report back all dev modules as hacked if they are in front of an official release.

Of course, strictly speaking they may not be hacked, but in my use of the hacked module I consider anything that diverges from the current official release to be hacked.

The above is a good stop-gap measure so that there are no longer any errors. However, I've finally got a chance to implement real support for this.

For each module in development, the attached patch uses the timestamp of the original download to clone the comparing repository, and check out the commit matching it. The is based on the excellent work done in #1074536: Git clone support and #1863504: Compare dev version against git; I just put it all together.

The only issue with this approach is that the info files will show up as different (as the data from the packaging script doesn't exist in the Git repositories), but I believe we should handle this more generally in another issue.

And here's the D8 version as well.

Thanks Colan, I will try to review this within the next few days (for D8 at least).

Tests well in D8, could use a bit of coding standards improvement, but it's consistent with the module in it's current state, so will go ahead and commit it. Thanks for the great work.

Will need to test for D7 prior to committing, will try to do this within the next 24 hours.

Added #2678312: Hide Git output when running Drush commands as a follow-up.

Here's a version that addresses some of the info file problems. There's no way to get the original package information so I think it makes sense to just copy what is in the existing files so it will match and not show a false change detection.

It looks for a line in the current module's info file starting with "; Information added by" and appends the text starting from that line to the module it downloads from git. If the line doesn't exist then the downloaded info file won't change so it should work with modules originally downloaded via git too. The search string is short so it will cover both "; Information added by Drupal.org [...]" and "; Information added by drupal.org [...]" which was in use before.

It could be extended to search for submodules and handle their info files too, but even as it is it gets rid of a lot of extra change detections.

Actually, could you not include the info-strings problem in the D7 version? The D8 version doesn't have this, and it has already been committed. Let's use another issue for that: #2609214: Ignore packaging script info file changes.

So #11 needs review.

I don't think #2609214: Ignore packaging script info file changes is really the same problem because that person is using a git checkout and not a development version with package info that can be read.

The code I added doesn't have any meaning without the rest of the patch. If #11 gets applied then I can make a separate issue for it. Until then, it would be an issue about a hypothetical fix for code that isn't even in the module yet, and I don't think that makes sense.

I think it would make more sense to commit #18, but I'm fine with whatever the maintainer wants to do.

+1 on patch #18 worked well for me. RTBC it, but did not look extensively at code.

patch #18 worked for me also

patch #18 worked

Okay, let's go with #18. Once that's committed, we can set the Status to Patch (to be ported), change the Version to D8, and then wait for a D8 patch with the interdiff.

In D7, this seems to cause problems when used with #2066371: Integrate hacked with site_audit & allow hacked to be installed globally. See new issue #3019685: Class 'hackedProjectWebDevDownloader' not found in hackedProject->identify_project() for details.