Re: [Module::Build] requires_one_of
* Daniel Staal [EMAIL PROTECTED] [2004-07-17 12:45]:
Modules must be written to the interface of the module they
use, and if they can pick from one of several alternatives,
they have to be written towards all of these.
So I don't think there's a place for virtual distributions in
the CPAN. The right approach is to explicitly state which
alternative dependencies a module can use.
But there are a *few*. [ snip: eg. DBDs, PGP/GPG ]
True.
That doesn't invalidate my point that most of the time, you want
to explicitly specify the list of incompatible alternative
dependencies you have written your module against.
As for handling the few cases where it does make sense, can't it
be done on the author side of things, such as by having a
{DBI,PGP}::Config module or some such? Its version would be
bumped when the generic interface is changed, so that one could
usefully depend on it.
Regards,
--
Aristotle
If you can't laugh at yourself, you don't take life seriously enough.
Re: META.yml keywords
* Randy W. Sims [EMAIL PROTECTED] [2004-07-17 12:45]: There is, however, another advantage to the catagory approach: Searching would likely be more consistent. It would help authors to place their modules so that they can be found with similar modules. It would also help ensure that users looking for a particular type module will get back a result set that is likely to contain all/most of the modules of that type. Why does it have to be either/or? There could be two keyword lists, one with fixed keywords, and the other freeform. Their names would have to be chosen carefully to suggest this as the intended use (rather than filling both with the same keywords) -- maybe ``keywords'' and ``additional_keywords'' or something. Regards, -- Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: META.yml keywords
On Sat, Jul 17, 2004 at 01:32:36PM +0200, A. Pagaltzis wrote: * Randy W. Sims [EMAIL PROTECTED] [2004-07-17 12:45]: There is, however, another advantage to the catagory approach: Searching would likely be more consistent. It would help authors to place their modules so that they can be found with similar modules. It would also help ensure that users looking for a particular type module will get back a result set that is likely to contain all/most of the modules of that type. Why does it have to be either/or? There could be two keyword lists, one with fixed keywords, and the other freeform. Their names would have to be chosen carefully to suggest this as the intended use (rather than filling both with the same keywords) -- maybe ``keywords'' and ``additional_keywords'' or something. I agree that If there is to be an official list of keyowrds then it shouldn't be either/or. The officials haven't regenerated the module list for 2 years, there's no reason to think that the keyword officials will stay up to date. That said, I don't think having 2 lists is useful. The author should supply a single list of keywords. Those that are on the official list are on the official list, those that aren't aren't. The search engine/indexer will be far better at figuring that out than the module author. Otherwise you are just obliging the authors to keep track of the official list and move keywords around in their meta info as the official list chnages. It would be up to the search engine to perhaps give more weight to official keywords. The search engine could also maintain official synonyms so that postgres and pg are indexed together, F
Re: META.yml keywords
* Fergal Daly [EMAIL PROTECTED] [2004-07-17 14:56]: That said, I don't think having 2 lists is useful. The author should supply a single list of keywords. Those that are on the official list are on the official list, those that aren't aren't. The search engine/indexer will be far better at figuring that out than the module author. Otherwise you are just obliging the authors to keep track of the official list and move keywords around in their meta info as the official list chnages. Which was exactly the purpose: to be able to make sure that the list with official keywords really does only contain official keywords, so a release tool can complain about misspellings f.ex. If you simply allow both in a single list, then netwrok will go unnoticed and make your module invisible to searches with the correct keyword. I don't think the existence of two lists should matter to the indexer -- official keywords in the freeform list should have the same value as official ones in the fixed keys list. That sort of defeats the above point, I guess, but a list for fixed keys only still helps those who want its benefits. It might suffice to have the release tool check the list and tell the user which keywords are official and which aren't, but I don't know if that is helpful enough -- I personally would like to be able to tell it to choke on all mistakes *except* those I specifically declared as known non-official ones. Regards, -- Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: Module name? CPAN::Distribution::Depends
On July 15, 2004 9:52:30 PM EDT, Robert Rothenberg wrote: I am working on a module that when given a CPAN distribution, it will determine what modules that distribution depends on by scanning the META.yml file or if that one is not present, the Makefile.PL file. Is that a good name for it? It differs from existing modules in that it merely parses the Makefile.PL file rather than try to compile or run it and look for what modules it requests. For most modules on CPAN, it is quite adequate. Rob: I took a look thru the TL CPAN::* and Module* namespaces yesterday and, contrary to my first impression, came to the conclusion that your module does indeed do something that other modules don't, mainly because it is more narrowly focused and modest. So I think it will be a useful addition to CPAN. I think you are correct in not wanting to create a TL Distribution:** namespace. However, I tend to agree with other posters that the best place for this will be under the Module::* namespace, not the CPAN::* namespace. My reasoning: (1) As comdog said, if this can apply to _any other_ form of distribution besides CPAN (and I suspect it can, or should), then it should not go in the CPAN namespace; and (2) the other modules that do things like yours are in the Module** namespace, so someone searching through that space will be able to make quick comparisons between your module and say, Module::Install, and determine which is better for his/her needs. Jim Keenan
Re: Cpan Ratings (Was: Future of the Module List)
Pardon my ignorance, but ... What is the 'default phone-home behavior' in the Makefile.PL's about which Randal was complaining? Is it the author's 'Perlish' coding style, in which he places statement-ending semicolons at the start of the line? Or something else? jimk
Re: Cpan Ratings (Was: Future of the Module List)
James Keenan writes: Pardon my ignorance, but ... What is the 'default phone-home behavior' in the Makefile.PL's about which Randal was complaining? The author wished to keep track of how widely his modules were used -- at least partially as motivation for bothering to write them. Originally he had something in Makefile.PL which downloaded a file from his own website then executed the contents of that file. (Among other things, it warned the would-be-installer if a newer version of the distro was available.) People pointed out how insecure this is, and the damage that could be done by somebody hijacking his server and substituting a malicious Perl script at that URL. Others simply didn't like the idea at all of being counted and monitored without their consent; this phone-home behaviour happened by default, without warning. Somebody merely running Makefile.PL (or the CPAN shell or whatever) wouldn't expect it. The author responded to the security problem by changing his installers to download a dynamically generated data file, not a Perl script, which still allowed him to do counting and have the installer warn about old versions, but didn't have the security risk. But this still happened without warning, and would be unexpected to most users. Several people, Randal included, found this intrusive and unacceptable. I see that a few weeks ago the author removed all phone-home behaviour, so even this is no longer an issue. Smylers
Re: Cpan Ratings
On 7/17/2004 11:36 AM, James Keenan wrote: Pardon my ignorance, but ... What is the 'default phone-home behavior' in the Makefile.PL's about which Randal was complaining? Is it the author's 'Perlish' coding style, in which he places statement-ending semicolons at the start of the line? Or something else? First, let me say that I did not intend for any names to come up, nor did intend my previous message as any type of specific accusation. I was only pointing out an example of percieved misuse that I had stumbled across a while back, and that I thought was relevant to this discussion. For anyone who wants to see the Makefile.PLs in question they can still be found on some mirrors by googling for, say, 'CGI-Builder-1.24'. Currently, I find them at http://cpan.cbn.net.id/authors/id/D/DO/DOMIZIO/. There are two separate issues here. The first, whether this author did violated some implicit moral code in the way he/she wrote the Makefile.PL. This issue only matters in that if it was something really wrong, then the reviewer might be justified in doing what he did. The behavior in question is that the Makefile.Pl will check to see if LWP is installed, and if it is try to contact the author's website to see if there is a more recent version of the module and if so to notify the user. I guess the main problem with this is that it does so without giving the user a choice. I don't agree with this behaviour. As an option it would be acceptable. Note that there is a module on CPAN that also polls for modules across the internet: ExtUtils::AutoInstall. The major difference, as it relates to this discussion, is that it polls CPAN, a known and trusted site. However, I don't think this justifies the reviewers actions. And that is the second issue, the one relevant to this discussion: Was this a misuse of CPAN Ratings? Randy.
Re: [Module::Build] requires_one_of
On Jul 16, 2004, at 7:48 PM, Randy W. Sims wrote: It looks like maybe we could use 'virtual' packages like I mentioned below to solve this: YAML: requires: [db_driver]: postgresql || mysql [postgresql]: DBD::Pg: 0 DataTime::Format::Pg: 0 [mysql]: DBD::mysql: 0 DataTime::Format::mysql: 0 Square brackets denote virtual packages or macros. This should solve all the issues you mention as far as YAML goes. The Build.PL file is much more flexible; we can express these dependencies in many ways. There is not much of an issue there. Yes, that works for me. I guess one other thing that needs to be considered is: allowing other modules to make use of this. I think one of the things we wanted to allow is for the actual package being installed to access some of the same functionality in order to allow/disallow some functionality. For example, some modules will run in an enhanced mode if a module is present. Well, this is what recommends is for, no? Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 16, 2004, at 7:58 PM, Daniel Staal wrote: A virtual package in these cases would allow new modules to be added to the 'supports' list quite easily, and could allow for simpler test scripts. It is of limited utility, sure, but it is a non-zero utility. And the ability might encourage more people to create modules that could be virtualized this way. I guess you could say that it's of limited utility, but to my mind, it will make creating Module::Build-powered installer scripts for larger applications (such as RT and Bricolage, not to mention the 1000s of corporate applications out there) much easier. I'm glad you're in favor of the idea. :-) Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 17, 2004, at 4:26 AM, A. Pagaltzis wrote:
That doesn't invalidate my point that most of the time, you want
to explicitly specify the list of incompatible alternative
dependencies you have written your module against.
How does the proposed solution not do that?
As for handling the few cases where it does make sense, can't it
be done on the author side of things, such as by having a
{DBI,PGP}::Config module or some such? Its version would be
bumped when the generic interface is changed, so that one could
usefully depend on it.
There's still the issue of making people install one or another of the
array of possible modules. This is independent of the implementation,
IMO.
Regards,
David
smime.p7s
Description: S/MIME cryptographic signature
Re: META.yml keywords
On Jul 17, 2004, at 7:39 AM, Smylers wrote: Warning: Wild conjecture and multiple unrelated crazy ideas ahead. This is becoming _way_ too complicated. Agreed. And I still reckon most humans are approximately appalling at picking appropriate keywords anyway. A system like you're proposing still requires an individual module's author to think of the right keywords and bother to do this, which is putting a single-point of failure in the system. Agreed. However, improved Cpan searching would be welcome. Agreed. Note that the primary contribution of search.cpan.org is that it has a really nice interface and lots of functionality. But its actual search algorithm still isn't very good (it just uses WAIT, IIRC) - I think we could get far more mileage out of tuning the search engine better for the needs of perl-module searching, and perhaps doing stuff like grouping the results by distribution, than we'd ever get this way. And we wouldn't need to add complexity to the modules themselves. Smylers, I think your proposal is interesting but I don't think it's necessary for improving searching over CPAN modules. -Ken
Re: [Module::Build] requires_one_of
On 7/17/2004 12:25 PM, David Wheeler wrote: On Jul 16, 2004, at 7:48 PM, Randy W. Sims wrote: It looks like maybe we could use 'virtual' packages like I mentioned below to solve this: Erm, that should have been: YAML: requires: db_driver: [postgresql] || [mysql] [postgresql]: DBD::Pg: 0 DataTime::Format::Pg: 0 [mysql]: DBD::mysql: 0 DataTime::Format::mysql: 0 Keys in brackets (that is legal YAML isn't it?) are not evaluated until they are encountered in the value part of an expression who's key is not also a macro. Square brackets denote virtual packages or macros. This should solve all the issues you mention as far as YAML goes. The Build.PL file is much more flexible; we can express these dependencies in many ways. There is not much of an issue there. Yes, that works for me. Note that there is an implication for CPAN.pm and CPANPLUS. When a requirement with an OR condition is encountered they will have to either prompt the user for a selection or select the first option as a default. I'm not sure if there are any other compatability problems as I'm not real familiar with their implementation. But the author's should probably be consulted before making a final decision. Also, if there were a single module that all tools used to check requirements, it could include builtin macros for common virtual packages: DBD, DBM, Archiver, Encryption, ... Randy.
Re: [Module::Build] requires_one_of
On Jul 17, 2004, at 10:12 AM, Randy W. Sims wrote: Note that there is an implication for CPAN.pm and CPANPLUS. When a requirement with an OR condition is encountered they will have to either prompt the user for a selection or select the first option as a default. I'm not sure if there are any other compatability problems as I'm not real familiar with their implementation. But the author's should probably be consulted before making a final decision. Right, of course. Also, if there were a single module that all tools used to check requirements, it could include builtin macros for common virtual packages: DBD, DBM, Archiver, Encryption, ... Hrmm, yes, that would be nice, too. Did you just volunteer to write it? :-) Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 17, 2004, at 9:41 AM, Ken Williams wrote: Well, this is what recommends is for, no? Not quite. There's a new mechanism in M::B (it's done in CVS already, you can take a look) called features, which formalizes the concept of optional functionality that can be turned on or off. So even if a prerequisite module is installed, you don't necessarily have to use it (e.g. sometimes even though DBD::mysql is installed, I don't want to configure Alzabo to configure test with it). Ah, yes, that sounds nice. Cool. What are your thoughts on the virtual packages, Ken? Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
David Wheeler wrote: On Jul 17, 2004, at 10:12 AM, Randy W. Sims wrote: Also, if there were a single module that all tools used to check requirements, it could include builtin macros for common virtual packages: DBD, DBM, Archiver, Encryption, ... Hrmm, yes, that would be nice, too. Did you just volunteer to write it? :-) Well, there's a rough start on one at http://www.thepierianspring.org/CPAN-Metadata-0.00_02.tar.gz that I started several months ago, but haven't had time to finish (I haven't been very productive at anything for the last couple months :-( ). Amoung other things it takes all the version checking code out of Module::Build so that it can be used by other modules. I'll try to take a look at getting polished off if it seems like a good idea to everyone. Randy.
Re: Cpan Ratings
* Randy W. Sims [EMAIL PROTECTED] [2004-07-17 18:12]: For anyone who wants to see the Makefile.PLs in question they can still be found on some mirrors by googling for, say, 'CGI-Builder-1.24'. Currently, I find them at http://cpan.cbn.net.id/authors/id/D/DO/DOMIZIO/. Or, as always, on BackPAN, which archives all versions of all files ever to enter CPAN. Just pick any version of any of the maligned modules that is a little older than the ones available from CPAN: http://history.perl.org/backpan/authors/id/D/DO/DOMIZIO/ Regards, -- Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: [Module::Build] requires_one_of
* David Wheeler [EMAIL PROTECTED] [2004-07-17 18:29]:
On Jul 17, 2004, at 4:26 AM, A. Pagaltzis wrote:
That doesn't invalidate my point that most of the time, you
want to explicitly specify the list of incompatible
alternative dependencies you have written your module
against.
How does the proposed solution not do that?
Because it would be very silly to have a virtual package for
XML::Parser and XML::LibXML -- they can't be used as drop-in
replacements for one another. It *would* be useful to be able to
say I have written this module to work with XML::Parser v.$foo
or XML::LibXML v.$bar.
As for handling the few cases where it does make sense, can't
it be done on the author side of things, such as by having a
{DBI,PGP}::Config module or some such? Its version would be
bumped when the generic interface is changed, so that one
could usefully depend on it.
There's still the issue of making people install one or another
of the array of possible modules. This is independent of the
implementation, IMO.
You can depend on DBI::Config v.$foo to indicate I need a DBD
which understands version $foo of the DBD interface in that
case.
Regards,
--
Aristotle
If you can't laugh at yourself, you don't take life seriously enough.
Re: [Module::Build] requires_one_of
* David Wheeler [EMAIL PROTECTED] [2004-07-17 18:24]: On Jul 16, 2004, at 4:42 PM, A. Pagaltzis wrote: I don't think it can. Take the virtual package mail-transport-agent as an example, a dependency on which can be satisfied by exim, or postfix, or sendmail, or what have you. This works because all MTAs have a very similar interface. In other cases, a standard interface can be defined by Debian and wrapper scripts or some such can be written by the respective package maintainers. Yes, but this is up to the module developer, not to CPAN. If I write my module so it can use either DBD::Pg or DBD::mysql, I want to require users to install only one or the other, not both. But whether it does work with both is my responsibility. Yes, but what's your point? In fact you are arguing against virtual packages if the script only works with DBD::Pg or ::mysql, but not other DBDs -- because you'll need to depend on ::Pg or ::mysql explicitly even if there was a virtual package for any DBD. Obviously being able to list alternative dependencies is of more utility than the existence of virtual packages. Not only that, but the latter would also require changes to CPAN (how likely is that to happen?), whereas a list of alternative dependencies only requires a spec for its format and an implementation in EU::MM and/or Module::Builder. Regards, -- Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: [Module::Build] requires_one_of
* Ken Williams [EMAIL PROTECTED] [2004-07-17 18:43]: Not quite. There's a new mechanism in M::B (it's done in CVS already, you can take a look) called features, which formalizes the concept of optional functionality that can be turned on or off. Now what would be *very* cool is if I could say that I want some optional feature even though I don't have its prerequisites installed, and then have these prereqs automatically promoted to mandatory ones (which, presumably, would then be autoinstalled by whichever CPAN shell is in use). Regards, -- Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: [Module::Build] requires_one_of
* Randy W. Sims [EMAIL PROTECTED] [2004-07-18 01:14]: In this case I was calling db_driver a virtual package because it represents a requirement, but is not an actual module; It represents a requirement that may be satisfied by any of the two modules listed. It serves the same basic purpose as Debian's as in Debians system, but it is implemented differently in that it is defined on a per package basis. Yes, that proposal made sense, except for the name. :-) I have actually been arguing in favour of it, if you look at my mails. Can we use something other than virtual package please? Maybe deferred depence? Actually I don't know that this is a good name, it's just the best the comes to mind, and anything we can agree on that differs from virtual package would be fine, really. Let's just avoid further confusion and heartburn. Regards, -- Aristotle If you can't laugh at yourself, you don't take life seriously enough.
