Accept cpanfile as input to 'add'

[dagolden]

Pinto should take a cpanfile as input and recursively add the dependencies specified within.

[thaljef]

I think this would be part of the 'pull' command instead. When you 'add' you are placing a local distribution in the repository. I presume that you just want to populate the repository with the dependencies declared in the cpanfile. Or am I missing the point?

[dagolden]

I suppose it's closer to "pull" but maybe it needs to be more like this:

pinto pull --from cpanfile

The arguments to pull are modules/distributions so there should probably be a way to indicate a source

[holybit]

Should/could pinto auto detect a cpanfile in PINTO_REPOSITORY_ROOT as
opposed to --from?

On Fri, Jun 7, 2013 at 6:34 PM, David Golden notifications@github.comwrote:

I suppose it's closer to "pull" but maybe it needs to be more like this:

pinto pull --from cpanfile

The arguments to pull are modules/distributions so there should probably
be a way to indicate a source

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/79#issuecomment-19139936
.

[dagolden]

On Fri, Jun 7, 2013 at 11:46 PM, Joseph Crotty notifications@github.comwrote:

Should/could pinto auto detect a cpanfile in PINTO_REPOSITORY_ROOT as
opposed to --from?

No -- separate concepts entirely.

cpanfile is ideal for declaring dependencies in an application that is
going to be deployed from git rather than tarball, so doesn't need
Makefile.PL, etc.

Conceptually, we want Pinto to be able to easily grab its dependencies
without having to make it a tarball.

David Golden dagolden@cpan.org
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg

[holybit]

+1 on adding cpanfile support. @dagolden thanks for the clues on cpanfile and it's use. I get it now for the most part. I am using pinto currently as a way to store reqs for an application so cpanfile would be ideal. Currently, we use dzil to build a dist out of the app code for the sole purpose of adding deps to pinto.

[hartzell]

I have a slightly different twist on @dagolden's use case: even before deployment I'd like to be able to populate a local-lib for development work.

I want to be able to track the particular set of modules that are known to work (or that were used in a release, or that are otherwise canonical) in my VCS along side the rest of my project's information. At the moment I have that information indirectly, as the "the set of modules that live in the stack named ..." but it's not located "close" enough to the rest of the information about the project and it is subject to monkey-business (change the stack, delete the stack, blow away the repository because we didn't think you were using it, etc...).

In fact, I think I'd also/rather like to be able populate a stack from [something like] a cpanfile.snapshot file that precisely describes exactly the set of packages I want/need.

It would also be useful for pinto list to be able to dump a cpanfile.snapshot.

(I've asked Jeff for guidance about whether/how I might contribute some of this functionality)

[thaljef]

It would also be useful for pinto list to be able to dump a cpanfile.snapshot.

This doesn't produce a cpanfile.snapshot, but it does precisely capture the contents of the stack:

pinto -r /path/to/repo list --format %a/%f | sort | uniq

So you could keep this close to home by stashing the output in your VCS. And then you can feed it directly to cpanm or pinto.

[thaljef]

but it's not located "close" enough to the rest of the information about the project and it is subject to monkey-business (change the stack, delete the stack, blow away the repository because we didn't think you were using it, etc...).

Deleted stacks can be recovered, but that will require some consulting fees :)

If you delete the whole repository, then you can reconstruct your CPAN dependencies from that list But all your locally added dists will be gone.

[hartzell]

Jeffrey Ryan Thalhammer writes:

but it's not located "close" enough to the rest of the
information about the project and it is subject to monkey-business
(change the stack, delete the stack, blow away the repository because
we didn't think you were using it, etc...).

Deleted stacks can be recovered, but that will require some consulting fees :)

If you delete the whole repository, then you can reconstruct your
CPAN dependencies from that list But all your locally added dists
will be gone.

Part of my release process is stashing a copy of the tarball in the
'dists' branch of the svn repo (a la
Dist::Zilla::Plugin::Subversion::ReleaseDist), so it would be
unpleasant but recoverable.

On the other hand, by the time someone's blown away my pinto
repository I have to wonder what shape the rest of my world is
in... ;(

g.

[revmischa]

I would use Pinto if this was an option. I have a giant giant cpanfile, and I can't just manually add each dependency

[hartzell]

I have a fork that adds this feature, if I understand your need correctly. Jeff is looking at the pull request.

Pull request: #144

Fork: https://github.com/hartzell/Pinto

Does it do what you need?

[thaljef]

The more I think about this, the more I like it. Just need to hammer out some of the implementation details. My thoughts on that are here: #144 (comment)

[thaljef]

I have a giant giant cpanfile, and I can't just manually add each dependency

I the interim, I think converting a cpanfile into a plaintext list of targets for Pinto should be pretty simple. The code in @hartzell 's patch would get you 90% of the way there.

[thaljef]

@revmischa this should do the trick for now: https://gist.github.com/thaljef/52840fd60dfabc94f151

But I agree having this built into Pinto would be better.

[thaljef]

@revmischa it was good to see you at the SF.PM meetup. I hope you found the presentation helpful.

I'm going to work on adding support for cpanfiles this week.

[benrifkah]

Jeff, does your plan for this support include pulling dependencies defined dynamically when a distribution is built?

[mcallaway]

Any updates here?

[prat0088]

Bumping this issue. I had a need for this feature today.