Create a Alien::Base::ModuleBuild::Repository::Git to handle downloading source from Git repos

[zmughal]

Some projects only release their code via Git and it might be useful to have a way to specify a Git repo along with a Git commit SHA or a version tag.

[plicease]

I had this in the back of my mind for a while now too. We can use something like Git::Wrapper to fetch git based projects, but it isn't reliable enough to make a hard prereq for Alien::Base. It could be injected as a prereq for projects that require it only, or we could write a stand alone Alien-Base-ModuleBuild-Repository-Git. The issue I see here is that the API for Alien::Base::ModuleBuild::Repository is not documented, and arguably could use some love. I would like to see the repository fetch be more pluggable in general.

[jberger]

On Tue, May 26, 2015 at 7:21 AM Graham Ollis notifications@github.com
wrote:

I had this in the back of my mind for a while now too. We can use
something like Git::Wrapper to fetch git based projects, but it isn't
reliable enough to make a hard prereq for Alien::Base. It could be
injected as a prereq for projects that require it only, or we could write a
stand alone Alien-Base-ModuleBuild-Repository-Git.

It does seem useful, though I would encourage sticking to releases (tags)
rather than pulling master.

The issue I see here is that the API for
Alien::Base::ModuleBuild::Repository is not documented, and arguably could
use some love. I would like to see the repository fetch be more pluggable
in general.

Yes, indeed. I had grand architecture plans for that whole system.
Pluggable mechanisms for selecting versions etc. Remember that one of my
design goals was not to have to release a new version of the CPAN module
when the upstream library got a (compatible) update.

—
Reply to this email directly or view it on GitHub
#124 (comment)
.

[plicease]

@jberger I am not sure what you are referring to as I did not suggest pulling from master. I was discussing how to specify git itself as a prerequisite reliably. I have had good experience with using Git::Wrapper, but it barfs in either config or test if you do not have git. If ::Repository::Git were in a separate dist with a prereq on Git::Wrapper then it is less problematic.

[jberger]

No, you didn't say anything about that, I was just mentioning it off the
cuff as a reminder. I know that @preaction has had to deal with tests
depending on git state, do you have any thoughts?

On Tue, May 26, 2015 at 9:28 AM Graham Ollis notifications@github.com
wrote:

@jberger https://github.com/jberger I am not sure what you are
referring to as I did not suggest pulling from master. I was discussing how
to specify git itself as a prerequisite reliably. I have had good
experience with using Git::Wrapper, but it barfs in either config or test
if you do not have git. If ::Repository::Git were in a separate dist with a
prereq on Git::Wrapper then it is less problematic.

—
Reply to this email directly or view it on GitHub
#124 (comment)
.

[preaction]

I usually just add my Git-interaction module as a "recommends" and then:

use Test::More;
BEGIN { eval 'use Git::Repository; 1;' or plan skip_all => 'Git::Repository required for this test' };

I think it'd be better to have it as a separate dist because the author of the CPAN module using the Git version would need to explicitly depend on either it, or the Git module you use.

[plicease]

Does not solve this entirely but I also did want to just mention that github based projects can be downloaded (by tag, branch sha, etc) through the http interface:

https://github.com/Perl5-Alien/Alien-Base/archive/69d75834c73b8982df1af9f12684454a42a67c55.zip

a ::Repository::GitHub could find the most recent tag using the GitHub API and then download that one via the http interface. The advantage here is that you don't have a dep on git. Obviously the disadvantage is that it only supports github hosted projects.

[plicease]

I wanted to add a note that @jberger and I were talking about AB at YAPC::NA this week and I said that I thought the fetch mechanism needed an overhaul and he agreed (or at least agreed that would be okay). I am going to try and take a stab at it in the next couple of months and will likely use git support as a use case for the plugability aspect.

[plicease]

Here is an example of how you could use git as a package source using dontpanic under the Alien-Build recipe system:

use alienfile;

probe sub { 'share' };

share {

  download [
    [ "git clone --bare https://github.com/Perl5-Alien/dontpanic.git" ]
  ];

  extract [
    [ "git clone %{alien.install.download}" ]
  ];

  plugin 'Build::Autoconf' => ();

  build [
    'git checkout v1.00',
    'bash autogen.sh',
    '%{configure} --disable-shared --prefix=%{alien.install.prefix}',
    '%{make}',
    '%{make} install',
  ];


};

[mohawk2]

I'd like as much as possible to use other people's work for this stuff - is it possible to use cpanm's code directly to achieve the build-from-git?

[plicease]

@mohawk2 Not sure, I suspect that it is that it is perl/cpan specific, but if someone can point me to an API we can evaluate it. The point here is less "hey look I can use Alien::Build to download from git" and more "hey look I can use Alien::Build to download as long as there is a command to do it." Alien::Build has a negotiation mechanism for picking the best tools for the actual downloading from common protocols, like http, ftp, local file, but for stuff that hasn't been added to the core yet, (like git atm) being able to provide a command that does the trick is very powerful.

[zmughal]

An example of this that I had in mind was CastXML. It has no release tags.

[plicease]

This example works with CastXML for the download, although the build fails:

https://github.com/plicease/Alien-Build-Git/blob/master/examples/alienfile.castxml

I am going to release Alien-Build-Git probably later today or tomorrow.

I consider this issue addressed.