[perl #38262] get external modules out of the parrot repo
Jerry Gay
# Please include the string: [perl #38262]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38262 >
perl modules necessary for parrot configuration, development, and
testing have been either committed to the parrot repo, assumed to be
installed by the user, or (in some cases) checked for in code that
uses them.
this mish-mash is causing confusion for developers, testers, and end
users of parrot. all of them are left asking the same question, "what
external modules do i need to use parrot?"
we should have a better answer than "run it and see."
i think that better answer should be in the form of CPAN bundles. a
development bundle (Bundle::Parrot::Devel), a test bundle (::Test),
perhaps a seperate smoke bundle (::Smoke), and perhaps a bundle for
end users (::Install.)
installation of the necessary modules should be checked at configure
time, and an informative message should be given to the user if there
are missing dependencies.
i'm sure i've left things out, so please fill in details where you
deem appropriate. the sooner this task is specified and implemented,
the easier it will be for others to use/develop/test parrot.
~jerry
Bernhard Schmalhofer
># New Ticket Created by jerry gay
># Please include the string: [perl #38262]
># in the subject line of all future correspondence about this issue.
># <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38262 >
>
>
>perl modules necessary for parrot configuration, development, and
>testing have been either committed to the parrot repo, assumed to be
>installed by the user, or (in some cases) checked for in code that
>uses them.
>
>this mish-mash is causing confusion for developers, testers, and end
>users of parrot. all of them are left asking the same question, "what
>external modules do i need to use parrot?"
>
>we should have a better answer than "run it and see."
>
>i think that better answer should be in the form of CPAN bundles. a
>development bundle (Bundle::Parrot::Devel), a test bundle (::Test),
>perhaps a seperate smoke bundle (::Smoke), and perhaps a bundle for
>end users (::Install.)
>
>
We could also go the other way. Put everthing we need into the Parrot
repository, so that the answer to the above question would be:
Nothing, it is all in the distribution.
- Bernhard
Jerry Gay
> perl modules necessary for parrot configuration, development, and
> testing have been either committed to the parrot repo, assumed to be
> installed by the user, or (in some cases) checked for in code that
> uses them.
>
> this mish-mash is causing confusion for developers, testers, and end
> users of parrot. all of them are left asking the same question, "what
> external modules do i need to use parrot?"
>
> we should have a better answer than "run it and see."
>
where they're used:
~ Class::Struct -- can't find it used anywhere. recommend deletion.
~ Digest::Perl::MD5 -- used by dev/build tools.
~ File::Which -- used by configure
~ Parrot::* -- used by config, build, test. not really external
modules, recommend they stay.
~ Parse::RecDescent -- used by some languages in testing
~ Pod::Simple -- used by Parrot::Docs::* modules
~ Pod::Escapes -- used by Pod::Simple
~ Test::* -- used by test and some languages in testing
~ Text::Balanced -- used by build, and Parse::RecDescent
i've only given recommendations for obvious choices here. comments welcome.
~jerry
Jerry Gay
> >testing have been either committed to the parrot repo, assumed to be
> >installed by the user, or (in some cases) checked for in code that
> >uses them.
> >
> >this mish-mash is causing confusion for developers, testers, and end
> >users of parrot. all of them are left asking the same question, "what
> >external modules do i need to use parrot?"
> >
> >we should have a better answer than "run it and see."
> >
> >i think that better answer should be in the form of CPAN bundles. a
> >development bundle (Bundle::Parrot::Devel), a test bundle (::Test),
> >perhaps a seperate smoke bundle (::Smoke), and perhaps a bundle for
> >end users (::Install.)
> >
> >
> We could also go the other way. Put everthing we need into the Parrot
> repository, so that the answer to the above question would be:
>
> Nothing, it is all in the distribution.
>
already a standard repository for these modules, so why clutter the
parrot repo? users can then install only the cpan bundles they need,
rather than a whole host of modules they won't use if they're not
testers or developers.
~jerry
Joshua Hoblitt
> i think that better answer should be in the form of CPAN bundles. a
> development bundle (Bundle::Parrot::Devel), a test bundle (::Test),
> perhaps a seperate smoke bundle (::Smoke), and perhaps a bundle for
> end users (::Install.)
The whole point of 'Bundles' is so that you don't have to install a
bunch of modules by hand. Creating 3 or 4 bundles that all have to be
installed just so that you can build and test parrot is really defeating
the purpose. There should be just one bundle if any at all.
> installation of the necessary modules should be checked at configure
> time, and an informative message should be given to the user if there
> are missing dependencies.
That's just another configure step but it had better be run first...
-J
--
Chromatic
> > installation of the necessary modules should be checked at configure
> > time, and an informative message should be given to the user if there
> > are missing dependencies.
> That's just another configure step but it had better be run first...
This sounds an awful lot like what a Makefile.PL or a Build.PL does.
-- c
Chip Salzenberg
> true, but i think DRY (don't repeat yourself) applies here. there's
> already a standard repository for these modules, so why clutter the
> parrot repo?
Yes. Those who do not understand CPAN, etc.
There should be a single CPAN bundle which, when installed, will pick
up everything that a Parrot developer/tester requires. If you want to
go the extra mile and create sub-bundles for other purposes, like
testing-only, that's OK too. But unless the testers complain about
having more Damian code sitting on their hard drive, I don't see any
point in distinguishing dev from test.
I envision a "fat parrot" tarball which includes not only the basic
"thin parrot", but also required non-standard Perl modules, ICU, and
other dependencies that a bare Unix system would not have. That
should meet the needs of those who can't easily access the net during
installation.
That takes care of the tarball policies. Any system with a customized
installer system will impose its own policies and practices on the
developer who's foolhardy^Wbrave enough to package Parrot, so there's
no point in me trying to dictate anything for them.
--
Chip Salzenberg <ch...@pobox.com>