Re: [Module::Build] requires_one_of
On 7/18/2004 5:14 AM Smylers wrote: [...] Rather than the dependent app (or module) having a list alternatives that are known to work, it could instead depend on some 'abstract' package. Other distros are then able to say that they 'provide' that abstract package. So if another module is writtent that has equivalent functionality and the same interface then it just needs to label itself as 'provide'-ing that 'abstract' package, and the dependent app will just work with it. That requires the other distro authors to modify their packages. If they don't, then the feature can't be used. Take modules which interface with the serial port, for example. There's Win32::SerialPort (which hasn't been updated in years), and there's Device::SerialPort. One is for Windows, the other for Unix and imitates the Windows interface. So a module which needs the serial port requires either Win32::SerialPort or Device::SerialPort. My only way around it for some of the GPS::* modules I wrote was to say it 'recommends' both modules, which it really doesn't. I could put a dynamic config in the Build.PL but that causes the Makefile.PL and META.yml to reflect the platform that the dist was built on. Not good. It makes more sense to say 'requires_one_of'. Changes would only have to be made to the modules that handle builds and installation. Nobody else needs change their distros unless they want to use that feature. That nicely puts control of whether a distro provides certain functionality in control of each distro's author; the knowledge is in the system as a whole, and no one person has to keep an exhaustive list up to date. What one person needs to keep an exhaustive list? An exhaustive list of what? Expecting hundreds of CPAN authors to change their distros, and to have groups of them agree on abstract interfaces to provide, is not practical. Also, David has an app that depends on something Pg-or-mysql-like; suppose I do too, as do several other people. When another Pg-or-mysql-providing module appears it doesn't make sense for every single one of us app authors to have to note this, tweak our install settings, and upload a new version to Cpan; that's lots of duplicated and redundant effort. The choice as to whether to support another feature is up to a module author. If you don't want to put the extra work in, don't. Other authors would. The obvious flaw in my proposal for this particular instance is that Pg and mysql don't provide identical interfaces, so I'm guessing that David hasn't written code that just happens to work with either of them but has conditions in it specifically to deal with their differences. To make a 'provides' feature work, those differences would have to be abstracted out elsewhere. ...
Re: [Module::Build] requires_one_of
On Jul 17, 2004, at 3:13 PM, A. Pagaltzis wrote: * 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). Yup, that's in the plan. It's not implemented yet, though. Note there's some precedent for this idea in Module::Install. -Ken
Re: [Module::Build] requires_one_of
On Jul 18, 2004, at 10:08 AM, David Wheeler wrote:
On Jul 17, 2004, at 8:57 PM, David Wheeler wrote:
Agreed. I'm racking my brains (and the brains of those around me),
but I'm not coming up with anything. I like finding the right
language for things, though, so I'll have to think about it...
Hrm, I kind of like Smylers' suggested term, abstract. Maybe
abstract_requires in Module::Build?
Sorry I haven't had a lot of time to chime in - we had the baby niece
nephew over the weekend.
Unfortunately abstract is already taken in the META.yml: it's a
short descriptive phrase of the module.
Regarding the concept-formerly-known-as virtual packages, I think I'd
like them to tie into the features concept more. I think perhaps
it's time to write that boolean requirement specification stuff, and
then we can use that both in the normal requirement specs and the
requirement specs for a declared feature.
The idea would look something like this:
in the Build.PL --
features = {
# Old-style requirement spec
'yaml_support' = {
description = Can read write YAML
files,
requires = { 'YAML' = 0.13 },
recommends = { 'YAML' = 0.49 },
},
# New-style requirement mini-language spec
'dbi_support' = {
description = Can read write
databases,
requires = q{
DBI = 1.0 ,
(DBD::mysql = 1.5 ||
DBD::Postgres)
},
},
In other words, when the value of requires or one of the other
dependency items has a string value instead of a hash value, it means
that we're using the mini-language to express those dependencies. It
can also be used at the top level of the distribution, not associated
with any sub-feature.
Then, if we need macros (which is I think probably a better term than
virtual packages) we can add them in, but I think we can probably get
by for a long time (perhaps eternally) without them.
-Ken
Re: [Module::Build] requires_one_of
On Jul 19, 2004, at 8:32 AM, Ken Williams wrote:
'dbi_support' = {
description = Can read write
databases,
requires = q{
DBI = 1.0 ,
(DBD::mysql = 1.5 ||
DBD::Postgres)
},
},
In other words, when the value of requires or one of the other
dependency items has a string value instead of a hash value, it means
that we're using the mini-language to express those dependencies. It
can also be used at the top level of the distribution, not associated
with any sub-feature.
What if I need
( (DBD::mysql DateTime::Format::mysql)
|| (DBD::Pg DateTime::Format::Pg)
)
? And how would I specify required version numbers for those modules?
Then, if we need macros (which is I think probably a better term than
virtual packages) we can add them in, but I think we can probably
get by for a long time (perhaps eternally) without them.
Yes, but I do want the installer to report that one of the required
sets of packages for a feature is not installed. That's do-able, yes?
Regards,
David
smime.p7s
Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
Ken Williams wrote:
On Jul 18, 2004, at 10:08 AM, David Wheeler wrote:
On Jul 17, 2004, at 8:57 PM, David Wheeler wrote:
Agreed. I'm racking my brains (and the brains of those around me),
but I'm not coming up with anything. I like finding the right
language for things, though, so I'll have to think about it...
Hrm, I kind of like Smylers' suggested term, abstract. Maybe
abstract_requires in Module::Build?
Sorry I haven't had a lot of time to chime in - we had the baby niece
nephew over the weekend.
Unfortunately abstract is already taken in the META.yml: it's a short
descriptive phrase of the module.
Regarding the concept-formerly-known-as virtual packages, I think I'd
like them to tie into the features concept more. I think perhaps it's
time to write that boolean requirement specification stuff, and then we
can use that both in the normal requirement specs and the requirement
specs for a declared feature.
The idea would look something like this:
in the Build.PL --
features = {
# Old-style requirement spec
'yaml_support' = {
description = Can read write YAML
files,
requires = { 'YAML' = 0.13 },
recommends = { 'YAML' = 0.49 },
},
# New-style requirement mini-language spec
'dbi_support' = {
description = Can read write
databases,
requires = q{
DBI = 1.0 ,
(DBD::mysql = 1.5 || DBD::Postgres)
},
},
This method will require a complete expression parser, which is
admittably easy to implement. It just seems a little more error prone.
Also, expressions can be arbitrarily complex which can make it more
difficult to write expressions in a human readable format (David's
example hints at that complexity). That's why I liked extending the
existing format: less parsing for humans and machines.
features = {
...
dbi_support = {
description = Can read write databases,
requires = {
DBI = 1.0,
db_driver = q{ [mysql] || [pg] },
[mysql] = {
DBD::mysql = 1.5,
DataTime::Format::mysql = 0
},
[pg] = {
DBD::Pg = 0,
DataTime::Format::Pg = 0
},
},
},
This way most of the parsing is already done; Most all the terms are
already broken down into indivisible fields. It's more human readable
(IMO), though, perhaps a little more verbose. The macros help diffuse
the complexity of expressions.
Randy.
Re: [Module::Build] requires_one_of
Ken Williams wrote:
[...]
Regarding the concept-formerly-known-as virtual packages, I think I'd
like them to tie into the features concept more. I think perhaps it's
time to write that boolean requirement specification stuff, and then we
can use that both in the normal requirement specs and the requirement
specs for a declared feature.
To me, features are something that the module being installed offers,
rather than the thing the module requires in order to achieve its job.
With that in mind, if you take the following, and s/features/needs/ I
think it becomes eminently self-describing.
The idea would look something like this:
in the Build.PL --
features = {
# Old-style requirement spec
'yaml_support' = {
description = Can read write YAML
files,
requires = { 'YAML' = 0.13 },
recommends = { 'YAML' = 0.49 },
},
# New-style requirement mini-language spec
'dbi_support' = {
description = Can read write
databases,
requires = q{
DBI = 1.0 ,
(DBD::mysql = 1.5 || DBD::Postgres)
},
},
[...]
David
Re: [Module::Build] requires_one_of
On Jul 19, 2004, at 9:24 AM, Randy W. Sims wrote:
features = {
...
dbi_support = {
description = Can read write databases,
requires = {
DBI = 1.0,
db_driver = q{ [mysql] || [pg] },
[mysql] = {
DBD::mysql = 1.5,
DataTime::Format::mysql = 0
},
[pg] = {
DBD::Pg = 0,
DataTime::Format::Pg = 0
},
},
},
This way most of the parsing is already done; Most all the terms are
already broken down into indivisible fields. It's more human readable
(IMO), though, perhaps a little more verbose. The macros help diffuse
the complexity of expressions.
Even less parsing:
features = {
...
dbi_support = {
description = Can read write databases,
requires = {
DBI = 1.0,
db_driver = [qw(mysql pg)],
[mysql] = {
DBD::mysql = 1.5,
DataTime::Format::mysql = 0
},
[pg] = {
DBD::Pg = 0,
DataTime::Format::Pg = 0
},
},
},
Regards,
David
smime.p7s
Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
David Wheeler writes: On Jul 17, 2004, at 1:09 PM, A. Pagaltzis wrote: 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. Then I would require the Pg_or_mysql virtual package. Another point to consider is how such lists of alternatives could be added to, and whom should be doing the adding. If you've written something that depends on the Pg_or_mysql virtual package then your application will only install with either of those DBD drivers, even if somebody else later comes up with a compatible driver that your code would actually work with. This isn't far-fetched -- DBD::PgPP exists, for example, and has the aim of being compatible with DBD::Pg. Rather than the dependent app (or module) having a list alternatives that are known to work, it could instead depend on some 'abstract' package. Other distros are then able to say that they 'provide' that abstract package. So if another module is writtent that has equivalent functionality and the same interface then it just needs to label itself as 'provide'-ing that 'abstract' package, and the dependent app will just work with it. That nicely puts control of whether a distro provides certain functionality in control of each distro's author; the knowledge is in the system as a whole, and no one person has to keep an exhaustive list up to date. Also, David has an app that depends on something Pg-or-mysql-like; suppose I do too, as do several other people. When another Pg-or-mysql-providing module appears it doesn't make sense for every single one of us app authors to have to note this, tweak our install settings, and upload a new version to Cpan; that's lots of duplicated and redundant effort. The obvious flaw in my proposal for this particular instance is that Pg and mysql don't provide identical interfaces, so I'm guessing that David hasn't written code that just happens to work with either of them but has conditions in it specifically to deal with their differences. To make a 'provides' feature work, those differences would have to be abstracted out elsewhere. For example, something like this could work: David determines exactly which features are needed from a DBMS by his app, and specifies the interface that his app will use to access them. DBD::mysql::Wheelerish is written; it depends on DBD::mysql and provides DBD::Wheelerish; the code puts the defined interface on the 'MySQL'-specific stuff. Similarly DBD::Pg::Wheelerish does the same thing for 'Postgres', depending on DBD::Pg and providing DBD::Wheelerish. David's app then depends on DBD::Wheelerish; it doesn't care about (or even know) which DBMS is being used, and will happily work with anything that has those features. In the future somebody writes DBD::Oracle::Wheelerish. David's app will now just work with Oracle without him having to do anything with it at all. Almost certainly Wheelerish isn't the best name here, but without knowing what the features in question are I couldn't think of anything more specific. Smylers
Re: [Module::Build] requires_one_of
* Smylers [EMAIL PROTECTED] [2004-07-18 14:27]: [ lots of basic stuff about virtual packages ] For example, something like this could work: David determines exactly which features are needed from a DBMS by his app, and specifies the interface that his app will use to access them. And that is the weak point of such an approach and also the reason I do not think it will usefully encourage attempts at such abstraction (as Daniel Staal suggested): it requires a formally specified interface definition at the very beginning. That isn't something that happens in the real world; application needs evolve as the application changes -- internal interfaces change all the time, and having to set them in stone would in fact be a real hindrance to development. (Chant the refactoring mantra here with me.) As a reference point, go take a look at the virtual packages in Debian. How many of them are virtual packages for equivalent libraries, as opposed to equivalent apps? I don't think there are any. Regards, -- Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: [Module::Build] requires_one_of
On Jul 18, 2004, at 2:14 AM, Smylers wrote:
Also, David has an app that depends on something Pg-or-mysql-like;
suppose I do too, as do several other people. When another
Pg-or-mysql-providing module appears it doesn't make sense for every
single one of us app authors to have to note this, tweak our install
settings, and upload a new version to Cpan; that's lots of duplicated
and redundant effort.
I think that this will be the exception, really, and it's not much of
an onus for me to put something like this into my Build.PL:
requires = {
# Abstract package
db_driver = [qw(postgresql mysql)]
},
abstract_packages = {
postgresql = {
DBD::Pg = 0,
DateTime::Format::Pg = 0,
},
mysql = {
DBD::mysql = 0,
DateTime::Format::mysql = 0,
},
}
When someone adds Oracle support, then I'll be able to simply change it
to:
requires = {
# Abstract package
db_driver = [qw(postgresql mysql oracle)]
},
abstract_packages = {
postgresql = {
DBD::Pg = 0,
DateTime::Format::Pg = 0,
},
mysql = {
DBD::mysql = 0,
DateTime::Format::mysql = 0,
},
oracle = {
DBD::Oracle = 0,
DateTime::Format::Oracle = 0,
},
}
And re-release. I don't think that's too duplicating. But even for
those who do, I don't see why you wouldn't be able to simply build a
bundle that has the above requirements in it, and then all your app has
to do is require the bundle and its abstract requirements.
Regards,
David
smime.p7s
Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
On Jul 18, 2004, at 9:29 AM, A. Pagaltzis wrote: In terms of the word's meaning, I think that works. It just wish it was more catchy.. but if that's all we got, then that's what we got. I briefly thought about something involving multiplexing, but I can't think of any combination of words that is both accurate and not unwieldy or awkward. Okay then. So what needs to happen to make this a reality? Modification of the META.yml spec? Modification of Module::Build? And then of CPANPLUS and CPAN.pm? Regards, David smime.p7s Description: S/MIME cryptographic signature
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: [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: [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: [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.
Re: [Module::Build] requires_one_of
Moving the conversation over to module-authors...
On Jul 16, 2004, at 11:52 AM, Randy W. Sims wrote:
David Wheeler wrote:
On Jul 9, 2004, at 3:00 PM, David Wheeler wrote:
Yes, but what about applications that require one among a list of
modules? I'm thinking of things like DBIx::SearchBuilder, which
requires one of several DBDs, and various XML modules, which require
one among a list of parsers. In a case such as that, I don't know
what to do about META.yml.
Maybe there should be a way to specify that there is a requirement
for one among a list of modules? Or even that there one of several
groups of modules is required? Something like this:
requires_one_of {
dbd = {
DBD::Pg = {
DBD::Pg = 0,
DateTime::Format::Pg = 0,
},
DBD::mysql = {
DBD::mysql = 0,
DateTime::Format::mysql = 0
}
},
parser = {
XML::Parser = 0,
XML::LibXML = 0,
}
}
Here either XML::Parser or XML::LibXML is required, and either
DBD::Pg and DateTime::Format::Pg or DBD::mysql and
DateTime::Format::mysql. These could also be represented in YML, of
course.
Should I resend this proposal to the module authors list?
I think one of Ken's original ideas (and one that I like really like)
is to provide a flexible language for describing dependencies,
including situations like you describe above. IIRC, the idea was to
provide a way of saying things like:
DBD::Pg 0 || DBD::mysql 0
That's not bad, although it doesn't help to specify collections of
related modules like my proposal does. Also, AFAIK, the current
Module::Build syntax for version number requirements doesn't support
this, and isn't likely too, it seems to me, since module names are not
included in the version spec string. They're only the hash keys.
Debian's package manager does something different. A package can
belong to a 'virtual package'. For example there is a virtual package
for email-client. Any package that belongs to the virtual package
email-client would satisfy the dependency of another package that
depends on the that virtual package.
Hrm. That's not a bad idea. Not sure how that'd work with CPAN, though.
Bundles are the closest thing, and even with the successful
installation of a bundle doesn't mean that all of the modules it
includes have been successfully installed.
While I like debian's approach, I'm not sure it can easily be
retrofitted onto the current system. One way in which it might be
possible is to introduce macros such that you can define 'virtual
packages' in the META.yml file and the packages that satisfy it. Then
use that macro in the requirements. Of course, the thing that makes
Debians system nice is that you do not have to change the package that
has a requirement on a virtual package when a new package that also
fits the requirement is introduced. But that would require a database
of all CPAN modules.
Yes, which there is, in the module list, but it's pretty limited at
this point. I kind of like this idea, too, but I'm not sure how well it
will work. The advantage to my proposal, on the other hand, is that
it's fully self-contained in the META.yml.
module-authors might be able to come up with some other alternatives.
Moved there now. Thanks for the feedback.
Regards,
David
smime.p7s
Description: S/MIME cryptographic signature
Re: [Module::Build] requires_one_of
* David Wheeler [EMAIL PROTECTED] [2004-07-16 23:53]: Debian's package manager does something different. A package can belong to a 'virtual package'. For example there is a virtual package for email-client. Any package that belongs to the virtual package email-client would satisfy the dependency of another package that depends on the that virtual package. Hrm. That's not a bad idea. Not sure how that'd work with CPAN, though. 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. This is not at all comparable to the situation on CPAN. You can't just s/XML::Parser/XML::LibXML/g f.ex and expect it to work. 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. Regards, -- Aristotle If you can't laugh at yourself, you don't take life seriously enough.
