You are correct!!
I updated the script to dump the list of distributions it found into a file.
Here is an example of the file:
https://github.com/itcharlie/IDP_charlie/blob/master/perl_tools/dist_file_1388981451
You can see duplicate entries of distributions with different versions.
Take Dancer-Plugin-Database-Core for example:
The distribution file list has :
AMBS/Dancer/Dancer-Plugin-Database-Core-0.02.tar.gz
AMBS/Dancer/Dancer-Plugin-Database-Core-0.04.tar.gz
and my snapshot file contains:
Dancer::Plugin::Database::Core 0.04
Dancer::Plugin::Database::Core::Handle 0.02
Dancer::Plugin::Database::Core::Handle 0.02 module is still part of Dancer-Plugin-Database-Core-0.04 distribution.
Because of this I am planning to add some logic to the script so that it only adds the latest version of the distribution to the pinto repo. ( Is this really a good idea? )
If it helps, please feel free to take a copy of this tool and massage it any way you want in order to add similar feature to pinto .
]]>Yeah, working on Windows is a bit more challenging. On Unixoid varieties, you can count on having bash and at least some flavor of Perl, even if ancient, and you can do quite a lot with just those two. With Windows you can't count on much, so you're pretty much forced to compile something executable. Which is a bit more work than I was personally hoping to do. :-) Of course, if I eventually turn this into an official ... something (it's not really a module or or a standalone app), then perhaps others could contribute a good solution for the Windows side.
> Perhaps some kind of hybrid... Those who don't have Perl can use a script to get it, those who do just have to use the bundled libs...
Well, in this case, I'm mainly undertaking this in order to get it installed for people who do have Perl. The issue is, I don't know what version of Perl they have. I don't know if it's system Perl or perlbrew Perl or plenv Perl or some other sort of Perl. I don't know if they're on Linux or OSX. Maybe some of the dependencies I want to use for my app have XS components and therefore aren't amenable to being FatPacked. Maybe I don't want to restrict myself to an ancient subset of the Perl language just so people running ancient versions of Perl can use it (actually, there's no "maybe" about that one). Maybe I don't want to restrict myself to a politically correct subset of modules just so I don't have to endure criticisms about such-and-such using Devel::Declare which is a big bag of crack or thus-and-so using smartmatch which is "experimental!!" (ditto).
The point (for me) is that I want my app to use whatever it uses and you shouldn't have to care. So I keep my app's crap out of your way. That's all I'm shooting for.
]]>Two things there:
1) Maybe I should make building the separate Perl optional. It does take forever, even with the tests turned off. And that's a pretty big downside for adoption of your app. But there's just so many glitchy little things with not knowing what version of Perl is running your app. You have language features that you didn't realize were only introduced with version such-and-such and so anyone running version this-and-that gets an error. You get weird bugs because you were expecting a threaded Perl and you got unthreaded, or vice-versa. Having your own private Perl just makes so many things easier.
2) I do want to get Stratopan integrated into this solution eventually (as we chatted about via email a while back). The value that Stratopan can provide really comes to the fore when you have unreleased versions of modules to include, or modules that require small patches to work with your app. (There are probably even more situations that you can think of, being the Stratopan guy.) But you can do quite a lot with just cpanfile as well.
The Perl toolchain is great for distributing libraries, but lousy for distributing applications, especially if they contain lots of non-code assets. I think part of the problem is that there's no consensus on how user-space applications should be organized or where they should go on the file system.
I agree that's part of it. But I think there's more as well. The toolchain is also (at least currently) not equipped to get older versions of modules, in case newer ones break your code somehow. And it's not very well integrated with things like local::lib to enable separation of dependencies. Hell, half the value of Perlbrew to me is not having to figure out how to make local::lib work. Without Perlbrew (or plenv, I suppose, though I've not yet used it), just dealing with the fact that local::lib isn't a core module can make your brain hurt.
]]>