Re: Perl6 - Module::Build
by brian_d_foy (Abbot) on May 27, 2005 at 18:07 UTC
|
Although the directory tree is not formally laid out, there has been a lot of talk about it. The big changes that remember from the discussions are:
- Install multiple versions at the same time
- Tag modules with author name
- Uninstall capabilities
However, the installation targets shouldn't influence your design that much.
Don't limit your discussion to Perlmonks: a lot of other parts of the Perl universe have to work with whatever you come up with. You'll probably also want to work with (not separately) from the current Module::Build folks who have already thought a lot about this stuff.
Good luck :)
--
brian d foy <brian@stonehenge.com>
| [reply] [Watch: Dir/Any] |
Re: Perl6 - Module::Build
by theorbtwo (Prior) on May 27, 2005 at 19:09 UTC
|
In no purticular order, things that I would like to see:
- Pure perl is the right decision. For that matter, as far as possible, it should have no external dependencies. (Such as make.)
- I would suggest a design using /lots/ of mix-in modules -- it should be possible to install on a system with win32-ish names for things (.exe, .obj, .dll), but a unixish directory tree, by plugging and playing the approprate modules.
- It should be possible to get lots of metadata without running any free-form code, or it should be possible to run the code within the non-IO playground.
- It should be possible to express a very rich set of dependency information. Most importantly, it should be possible to express dependencies outside of the perl world -- on C-ish libraries, on implementation details, and on OS. ("This library requires pugs on win32 and the library http://www.libsdl.org with a version between 3.1 and 4.")
Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).
| [reply] [Watch: Dir/Any] |
Re: Perl6 - Module::Build
by Juerd (Abbot) on May 27, 2005 at 15:43 UTC
|
Anything will work, as long as it makes installing a non-system-wide copy very, very easy. Without the need of specifying a prefix. In fact, perhaps homedir installation (~/.perl6/lib/...) should be made default, and whatever directory is used for that should be in @*INC by default too.
| [reply] [Watch: Dir/Any] |
|
I second the home dir installation idea. Maybe not default, but definitely have an easy syntax to do home dir installations; something like perl Makefile.PL install_dir (replace Makefile.PL with whatever makes sense (my brain is a little fried right now from 12+ hours of trying to shoehorn XS modules into a poorly configured machine); hopefully you get the idea).
Update: I just saw this quote in [id://The St. Larry Wall Shrine], the irony was too much to pass up...
"What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
--Larry Wall in <1992Aug26.184221.29627@netlabs.com>
| [reply] [Watch: Dir/Any] |
Re: Perl6 - Module::Build
by Ovid (Cardinal) on May 27, 2005 at 19:27 UTC
|
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
Test coverage has nothing to do with module installation. However, build systems are for both those who install modules and those who create modules. Otherwise, it might make more sense to call this Module::Install or Module::Create. Since you can't have the former without the latter, why create a build system that only caters to one segment? I am not suggesting that this be one of the first features put in there, but it would be a valuable one.
Test coverage is an important (but neglected) part of ensuring software quality. Any tool that makes it easier to provide better quality software can only help Perl.
| [reply] [Watch: Dir/Any] |
|
|
|
| [reply] [Watch: Dir/Any] |
Re: Perl6 - Module::Build
by Corion (Patriarch) on May 27, 2005 at 19:33 UTC
|
Since you're going pure Perl, please don't repeat the mistake of Module::Build of not having a dry-run and no trace of attempted/failed steps. make -n tells me in great detail what it will try, and make itself tells me what it tried and how it failed. Both are very necessary when debugging the installation.
Update: Another important addition are two hard rules for the Perl code:
- No user interaction without defaults
- No loops, or at least no possibly infinite loops when the installation is not run interactively
A good way for that might be specialized functions like prompt_path and prompt_executable, that implement the looping themselves.
| [reply] [Watch: Dir/Any] |
|
You make it sound as if Module::Build is somehow coded to _not_ allow dry runs. I don't think this was a design decision Ken made, it's simply not in the code base at present.
There is a "fakeinstall" build target you can use to get a partial dry run (just of the parts done by ExtUtils::Install, aka module installation). I'm sure patches are welcome to expand dry-run functionality ;)
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
I run CPAN smoke tests, and the alarm() call has problems on Win32 Perl, so Makefile.PL does not get timed out when doing a CPAN smoke. Both rules have been evolved from the broken Makefile.PL that is the tradition of mod_perl, which dives into an infinite loop asking me for the location of httpd, over and over again, without a default and without user interaction. The subsequently generated long error email (after I kill the runaway process) then gets bounced back to me by x.perl.org in its entirety because it's too large.
To prevent authors of Makefile.PL from doing these stupid steps, I came up with these rules.
The first rule makes authors think about providing sensible defaults or even making the Makefile.PL actively search instead of always asking the user. This is a passive measure to make Makefile.PL find things even in absence of guidance by a user.
The second rule actively prevents authors from writing potentially infinite loops asking the same question, again and again, without ever getting an answer because there is no user.
| [reply] [Watch: Dir/Any] |
Re: Perl6 - Module::Build
by PodMaster (Abbot) on May 27, 2005 at 20:30 UTC
|
Currently both ExtUtils::MakeMaker and Module::Build
complicate the install step (which is just a copy operation)
by using some XS modules (Cwd),
which means that you can't upgrade those modules on platforms like win32 (can't delete .dll while it's use).
I'd like to not see this mistake repeated :)
Another thing I'd like to see is good detection of compilers, headers, external libraries, ...
The developer would only specify what his module needs to function (libexpat, version 2)
and the user would automatically be prompted if some things are missing (or might be named differently).
A user shouldn't be able to get past the Makefile.PL step if he's missing a C compiler,
expat.h, or version 2 of libexpat ...
With regards to tests, a developer need only write something like
test_prompt(
"need_socket",
"Needs to create sockets to blah.com",
"default if no default from config"
[ qw[t/sock1. t/sock2.t]]
);
test_prompt(
"need_server_socket",
[qw[t/servsock1. t/servsock2.t]]
);
And a user would be prompted if he'd like to run those tests,
with a defaults (need_socket, need_server_socket) being provided through a config file.
Also see Module::Install for ideas.
update: Whether to build manpages/htmldocs should also be user configurable
MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!" | I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README). | ** The third rule of perl club is a statement of fact: pod is sexy. |
| [reply] [Watch: Dir/Any] [d/l] |
|
Now I know I'm not the only one with problems with Cwd.
While it certainly should be built into perl.dll (speaking of Win32), it is not, and some non-trivial usages of Cwd from Perl built into C makes my program even segfault. I therefore trade portability and use Win32::GetCwd which in turn built into perl.dll
Also, during its execution it constantly checks for $^O, suspecting my script to start on Win32 and then continue working on VMS.
FWIW Cwd is a perfect example of poorly designed module, however visually it looks sane but implemented insane, yet its task is trivial.
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: Perl6 - Module::Build
by itub (Priest) on May 27, 2005 at 16:11 UTC
|
Maybe it would be nice to have an easy way of installing more than one version of a module. | [reply] [Watch: Dir/Any] |
|
for perl5 there is only that does just that.
| [reply] [Watch: Dir/Any] |
Re: Perl6 - Module::Build
by jonadab (Parson) on May 28, 2005 at 10:07 UTC
|
In addition to what everyone else has said, I'd like to NOT have to re-install modules every time I upgrade to a new Perl or a new Pugs or a new Parrot or whatever.
| [reply] [Watch: Dir/Any] |
Re: Perl6 - Module::Build
by Jaap (Curate) on May 28, 2005 at 12:18 UTC
|
I might be alone in this, but i'd like to see some way of installing it in one step, without make && make test && make install (or the Module::Build equivalents). | [reply] [Watch: Dir/Any] |
|
Isn't that make install?
MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!" | I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README). | ** The third rule of perl club is a statement of fact: pod is sexy. |
| [reply] [Watch: Dir/Any] [d/l] |
|
I never knew that worked. Why do they always say make && make test && make install then?
| [reply] [Watch: Dir/Any] |
|