Thread: [Module-build-general] A mini-language for dependencies?
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Ken W. <ke...@ma...> - 2003-02-19 04:49:54
|
Hey,
So, I think Dave was the first to suggest this, and now I'm thinking
it's maybe the right way to go too. I think we need a little boolean
mini-language to express module dependencies.
The reasoning is that some modules have complicated dependencies that
surpass even the capabilities of the current M::B system. When this
happens, the developer's only choice is to use perl code to set the
dependencies dynamically based on querying the user, poking around in
the environment (for instance, getting the version of perl or looking
at $^O), or whatever. This means that a comprehensive, static
dependency mapping much harder to maintain, since each dynamic
dependency creates an unknown blotch in the map.
Anything we can do to get these dependencies expressed in a static
declarative structure, rather than in runtime perl code, will help with
this kind of mapping.
Such a mini-language probably doesn't need to be very sophisticated -
probably just needs to support arbitrary boolean combinations, and have
a few things to represent things like the perl version and the
operating system.
The mini-language would probably be the province of a new module called
something like Module::Prereq or Module::Dependency, which
Module::Build would depend on (and because of a chicken/egg problem,
Module::Build can't actually use the mini-language to express this
dependency ;-).
I don't have a lot of experience designing mini-languages, but I'm
thinking it should do at least the following:
* Allow arbitrary boolean combinations of dependency on arbitrary
versions of modules
* Allow declarative branching based on perl version or OS
* Allow dependency specification based on feature sets, similar
to the way ExtUtils::AutoInstall groups things
* Let the author specify *why* a certain dependency is necessary,
especially in the case of optional dependencies
Here's a first stab at an example - it doesn't fulfill all of the above
criteria, and it's not very nice yet, but it could maybe get the ball
rolling.
-----------------------------------------------------------------------
SUBRULES:
$md = Crypt::MD5 | Crypt::MD4; # Subrules use '$' sigil?
REQUIRES:
perl 5.6.0; # Version number by itself, means "minimum required"
File::Basename
purpose => "To compute basenames for foo-function";
$md; # As defined above
(os = 'Windows' & Archive::Tar 0.23) # OS-dependent stuff
| (os != 'Windows' & Archive::Tar 0.17)
RECOMMENDS:
Term::ReadKey;
FEATURES:
feature1 => {
PURPOSE:
"Allows you to use feature 1"
REQUIRES:
Foo::Bar
}
-----------------------------------------------------------------------
Comments? Is there some precedent for this that I should follow?
One thing I specifically *haven't* addressed is external dependencies,
like libraries or shell commands. I don't know whether we want to get
into that stuff.
-Ken
|
|
From: Autrijus T. <aut...@au...> - 2003-03-06 03:50:58
|
On Tue, Feb 18, 2003 at 10:49:46PM -0600, Ken Williams wrote:
> I don't have a lot of experience designing mini-languages, but I'm=20
> thinking it should do at least the following:
>=20
> * Allow arbitrary boolean combinations of dependency on arbitrary
> versions of modules
>=20
> * Allow declarative branching based on perl version or OS
>=20
> * Allow dependency specification based on feature sets, similar
> to the way ExtUtils::AutoInstall groups things
>=20
> * Let the author specify *why* a certain dependency is necessary,
> especially in the case of optional dependencies
Below please find a sample of my current proposal of formalizing
EU::AI parameters into YAML so it can be written insite META.yml,
based on today's IRC discussion. I hope it to be self-descriptory.
The top-level "build_requires/recommends/requires" keys corresponds
with the -core feature in EU::AI parlance.
Comments welcome!
Thanks,
/Autrijus/
--- #YAML:1.0
build_requires:
Test::More: {}
recommends:
Acme::ComeFrom:
alternate:
Acme::ComeWith:
version: 0.05
reason: "I really likes it"
version: 0.02
requires:
Some::Module:
arch: MSWin32
perl: 5.6.0
version: 1.04
Other::Module:
version 1.53
arch: '!Solaris'
perl: 5.005
features:
- name: This is feature one
requires:
arch: MSWin32
Module::Foo:
perl: '<5.6.0'
version: 2.04
- name: Feature two
requires:
Lingua::ZH::TaBE: {}
recommends:
Lingua::EN::Inflect:
arch: '!MSWin32'
version: 3.03
|
|
From: <sc...@po...> - 2003-03-06 08:49:12
|
On Thu, Mar 06, 2003 at 11:51:12AM +0800, Autrijus Tang wrote:
> build_requires:
> Test::More: {}
> recommends:
> Acme::ComeFrom:
> alternate:
> Acme::ComeWith:
> version: 0.05
> reason: "I really likes it"
> version: 0.02
The 'alternate' syntax feels better handled like so
recommends:
Text::Bastardize: 0
Net Transport Agent:
LWP: 1.25
Net::FTP: 0.24
ie. what you need it for then those modules which will fulfill the need.
Its simple to read and write.
And then when you need all the extra information (arch, perl, etc...)
there's an optional rich syntax like you have below.
> requires:
> Some::Module:
> arch: MSWin32
> perl: 5.6.0
> version: 1.04
> Other::Module:
> version 1.53
> arch: '!Solaris'
> perl: 5.005
> features:
> - name: This is feature one
> requires:
> arch: MSWin32
> Module::Foo:
> perl: '<5.6.0'
> version: 2.04
> - name: Feature two
> requires:
> Lingua::ZH::TaBE: {}
> recommends:
> Lingua::EN::Inflect:
> arch: '!MSWin32'
> version: 3.03
--
|
|
From: Ken W. <ke...@ma...> - 2003-03-07 21:17:29
|
On Thursday, March 6, 2003, at 02:48 AM, sc...@po... wrote:
> On Thu, Mar 06, 2003 at 11:51:12AM +0800, Autrijus Tang wrote:
>> build_requires:
>> Test::More: {}
>> recommends:
>> Acme::ComeFrom:
>> alternate:
>> Acme::ComeWith:
>> version: 0.05
>> reason: "I really likes it"
>> version: 0.02
>
> The 'alternate' syntax feels better handled like so
>
> recommends:
> Text::Bastardize: 0
> Net Transport Agent:
> LWP: 1.25
> Net::FTP: 0.24
>
> ie. what you need it for then those modules which will fulfill the
> need.
> Its simple to read and write.
>
> And then when you need all the extra information (arch, perl, etc...)
> there's an optional rich syntax like you have below.
I'm not sure I'm convinced that YAML is really the best way to write
this information. That's why I suggested the creation of a
mini-language - YAML is a language for creating data structures, not
declarations of dependencies. My sense is that forcing things into
YAML tends to obscure the information.
If it can be done in easy YAML, and still be eminently readable, I'm
all for it. It does make the parsing easier. But I don't think it's
great to use 3-level nesting in the META.yml files, because you lose
the human readability and the ability to use brain-dead parsing on them.
That said, the real work in this task isn't in the parsing, it's in
turning the parse into a real check of the dependencies. So I'm not
sure there's a whole lot to gain by using YAML either. Recall that the
easy cases (modules with completely static dependencies) can just be
expressed using the current YAML declarations, so it's only the messy
cases that will need to use this anyway.
I should be able to post a counter-proposal within the next couple of
days.
-Ken
|
|
From: Brian I. <in...@tt...> - 2003-03-08 17:25:28
|
On 07/03/03 15:17 -0600, Ken Williams wrote:
>
> On Thursday, March 6, 2003, at 02:48 AM, sc...@po... wrote:
>
> > On Thu, Mar 06, 2003 at 11:51:12AM +0800, Autrijus Tang wrote:
> >> build_requires:
> >> Test::More: {}
> >> recommends:
> >> Acme::ComeFrom:
> >> alternate:
> >> Acme::ComeWith:
> >> version: 0.05
> >> reason: "I really likes it"
> >> version: 0.02
> >
> > The 'alternate' syntax feels better handled like so
> >
> > recommends:
> > Text::Bastardize: 0
> > Net Transport Agent:
> > LWP: 1.25
> > Net::FTP: 0.24
FWIW, This is also valid YAML:
recommends:
Text::Bastardize: 0
Net Transport Agent: { LWP: 1.25, Net::FTP: 0.24 }
> > ie. what you need it for then those modules which will fulfill the
> > need.
> > Its simple to read and write.
> >
> > And then when you need all the extra information (arch, perl, etc...)
> > there's an optional rich syntax like you have below.
>
> I'm not sure I'm convinced that YAML is really the best way to write
> this information. That's why I suggested the creation of a
> mini-language - YAML is a language for creating data structures, not
> declarations of dependencies. My sense is that forcing things into
> YAML tends to obscure the information.
>
> If it can be done in easy YAML, and still be eminently readable, I'm
> all for it. It does make the parsing easier. But I don't think it's
> great to use 3-level nesting in the META.yml files, because you lose
> the human readability and the ability to use brain-dead parsing on them.
>
> That said, the real work in this task isn't in the parsing, it's in
> turning the parse into a real check of the dependencies. So I'm not
> sure there's a whole lot to gain by using YAML either. Recall that the
> easy cases (modules with completely static dependencies) can just be
> expressed using the current YAML declarations, so it's only the messy
> cases that will need to use this anyway.
>
> I should be able to post a counter-proposal within the next couple of
> days.
>
> -Ken
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general
|
Thanks for helping keep SourceForge clean.
X