Thread: [Module-build-general] More version info in META.yml
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: <sc...@po...> - 2003-03-06 15:58:30
|
I was talking with Andreas last night about the META.yml idea. He mentioned
that it would be useful for PAUSE if in addition to having just the
version # for the whole distribution, it also had the version # for all
.pm files in the dist. That way PAUSE wouldn't have to check itself
(involving some gymnastics to make it safe).
At our end, its pretty simple. We just run the moral equivalent of
ExtUtils::MakeMaker->parse_version on each .pm file and encode that,
something like:
modules:
Module::Build: 0.16
Module::Build::Base:
Module::Build::Compat: 0.02
...etc...
Thoughts?
|
|
From: Ken W. <ke...@ma...> - 2003-03-08 18:15:25
|
On Thursday, March 6, 2003, at 09:58 AM, sc...@po... wrote: > I was talking with Andreas last night about the META.yml idea. He > mentioned > that it would be useful for PAUSE if in addition to having just the > version # for the whole distribution, it also had the version # for all > .pm files in the dist. That way PAUSE wouldn't have to check itself > (involving some gymnastics to make it safe). > > At our end, its pretty simple. We just run the moral equivalent of > ExtUtils::MakeMaker->parse_version on each .pm file and encode that, > something like: > > modules: > Module::Build: 0.16 > Module::Build::Base: > Module::Build::Compat: 0.02 > ...etc... > > Thoughts? > I think that makes sense. A couple of questions, though: 1) Would this be better in a separate file like VERSIONS or something? Probably not, but I just wanted to throw out the idea. The list could get pretty big for some distributions. Maybe that's okay. 2) What about .pm files that contain multiple packages? Should those packages be included too, like the PAUSE namespace indexer does? -Ken |
|
From: <sc...@po...> - 2003-03-08 19:38:36
|
On Sat, Mar 08, 2003 at 12:15:18PM -0600, Ken Williams wrote: > 1) Would this be better in a separate file like VERSIONS or something? > Probably not, but I just wanted to throw out the idea. The list could > get pretty big for some distributions. Maybe that's okay. It shouldn't be necessary to split it up, no. I think it would just confuse things anyway. > 2) What about .pm files that contain multiple packages? Should those > packages be included too, like the PAUSE namespace indexer does? Is the PAUSE indexer that smart? I don't think it is. Anyhow, doing that correctly sounds like Work. |
|
From: Ken W. <ke...@ma...> - 2003-03-08 19:43:42
|
On Saturday, March 8, 2003, at 01:38 PM, sc...@po... wrote:
> On Sat, Mar 08, 2003 at 12:15:18PM -0600, Ken Williams wrote:
>
>> 2) What about .pm files that contain multiple packages? Should
>> those
>> packages be included too, like the PAUSE namespace indexer does?
>
> Is the PAUSE indexer that smart? I don't think it is.
Yup, it is:
<<<<<<<<<<<<<<<<<<<<<< PAUSE indexer report <<<<<<<<<<<<<<<<<<<<<
...
Module::Build::Platform::Windows
version: undef
in file: Module-Build-0.16/lib/Module/Build/Platform/Windows.pm
status: indexed
Module::Build::Platform::Windows::BCC
version: undef
in file: Module-Build-0.16/lib/Module/Build/Platform/Windows.pm
status: indexed
Module::Build::Platform::Windows::GCC
version: undef
in file: Module-Build-0.16/lib/Module/Build/Platform/Windows.pm
status: indexed
Module::Build::Platform::Windows::MSVC
version: undef
in file: Module-Build-0.16/lib/Module/Build/Platform/Windows.pm
status: indexed
...
<<<<<<<<<<<<<<<<<<<<<< PAUSE indexer report <<<<<<<<<<<<<<<<<<<<<
-Ken
|
|
From: <sc...@po...> - 2003-03-08 21:53:38
|
On Sat, Mar 08, 2003 at 01:43:37PM -0600, Ken Williams wrote: > >> 2) What about .pm files that contain multiple packages? Should > >> those > >> packages be included too, like the PAUSE namespace indexer does? > > > > Is the PAUSE indexer that smart? I don't think it is. > > Yup, it is: Maybe we should borrow the code then? |
|
From: <and...@an...> - 2003-03-10 18:11:46
|
>>>>> On Sat, 8 Mar 2003 13:53:25 -0800, sc...@po... (Michael G. Schwern) said:
> On Sat, Mar 08, 2003 at 01:43:37PM -0600, Ken Williams wrote:
>> >> 2) What about .pm files that contain multiple packages? Should
>> >> those
>> >> packages be included too, like the PAUSE namespace indexer does?
>> >
>> > Is the PAUSE indexer that smart? I don't think it is.
>>
>> Yup, it is:
> Maybe we should borrow the code then?
In case you don't know, PAUSE code is available in a subversion
repository and in daily snapshots. Daily dumps of the subversion repo
are also there. The dumps and snapshots are at
ftp://pause.perl.org/pub/PAUSE/PAUSE-code/
The repository itself is
http://pause.perl.org:5459/svn/pause/trunk
or
https://pause.perl.org:5460/svn/pause/trunk
The http adresses can also be browsed.
The indexer is in cron/mldistwatch.
Problem is, it is not a tiny program but 2000+ lines long and probably
not easy to follow and dissect. What do you suggest?
--
andreas
|
|
From: Ken W. <ke...@ma...> - 2003-03-30 05:45:18
|
On Monday, March 10, 2003, at 12:11 PM, Andreas J. Koenig wrote: >>>>>> On Sat, 8 Mar 2003 13:53:25 -0800, sc...@po... (Michael G. >>>>>> Schwern) said: > >> On Sat, Mar 08, 2003 at 01:43:37PM -0600, Ken Williams wrote: >>>>> 2) What about .pm files that contain multiple packages? Should >>>>> those >>>>> packages be included too, like the PAUSE namespace indexer does? >>>> >>>> Is the PAUSE indexer that smart? I don't think it is. >>> >>> Yup, it is: > >> Maybe we should borrow the code then? > > In case you don't know, PAUSE code is available in a subversion > repository and in daily snapshots. Daily dumps of the subversion repo > are also there. The dumps and snapshots are at > > ftp://pause.perl.org/pub/PAUSE/PAUSE-code/ > > The repository itself is > > http://pause.perl.org:5459/svn/pause/trunk > or > https://pause.perl.org:5460/svn/pause/trunk > > The http adresses can also be browsed. > > The indexer is in cron/mldistwatch. Thanks. Am I right that something like the following is what we're aiming for? provides: Foo::Bar: file: Bar.pm version: 0.12 Foo::Bar::Baz: file: lib/Foo/Bar/Baz.pm version: ~ (the '~' is YAML for undef) > > Problem is, it is not a tiny program but 2000+ lines long and probably > not easy to follow and dissect. What do you suggest? So, I started hacking my way through that code, slurping the relevant bits into Module::Build::Base. It was going pretty well. But then I got to the part where we try to figure out the version of each package, and I nearly fainted. Since this is a pretty hard and dangerous task, maybe we ought to really get it right and have it in a module. Could we try to use Module::Info for this? Even if Module::Info doesn't work correctly, maybe the best thing to do would be to fix Module::Info. I'd just hate to spend a lot of time on this and have the code buried in Module::Build, when this is exactly the kind of thing Module::Info aims to do correctly. -Ken |
|
From: <and...@an...> - 2003-03-30 21:03:57
|
>>>>> On Sat, 29 Mar 2003 23:44:52 -0600, Ken Williams <ke...@ma...> said: > Am I right that something like the following is what we're aiming for? > provides: > Foo::Bar: > file: Bar.pm > version: 0.12 > Foo::Bar::Baz: > file: lib/Foo/Bar/Baz.pm > version: ~ Yes, I think so. >> >> Problem is, it is not a tiny program but 2000+ lines long and probably >> not easy to follow and dissect. What do you suggest? > So, I started hacking my way through that code, slurping the relevant > bits into Module::Build::Base. It was going pretty well. But then I > got to the part where we try to figure out the version of each > package, and I nearly fainted. :) > Since this is a pretty hard and dangerous task, See, it's not dangerous per se, it's only dangerous on PAUSE. The META.yml file will only be generated on the developer's own box, so there's no need to protect from that sort of malicious code. > maybe we ought to really get it right and have it in a module. > Could we try to use Module::Info for this? Even if Module::Info > doesn't work correctly, maybe the best thing to do would be to fix > Module::Info. I believe that MakeMaker's parse_version does a pretty good job and Module::Info claims to follow MakeMaker's lead. > I'd just hate to spend a lot of time on this and have the code buried > in Module::Build, when this is exactly the kind of thing Module::Info > aims to do correctly. I'm agnostic on this question. -- andreas |
|
From: Ken W. <ke...@ma...> - 2003-03-30 21:20:22
|
On Sunday, March 30, 2003, at 03:03 PM, Andreas J. Koenig wrote: >> Since this is a pretty hard and dangerous task, > > See, it's not dangerous per se, it's only dangerous on PAUSE. The > META.yml file will only be generated on the developer's own box, so > there's no need to protect from that sort of malicious code. Very good point. >> maybe we ought to really get it right and have it in a module. >> Could we try to use Module::Info for this? Even if Module::Info >> doesn't work correctly, maybe the best thing to do would be to fix >> Module::Info. > > I believe that MakeMaker's parse_version does a pretty good job and > Module::Info claims to follow MakeMaker's lead. I think MakeMaker is doing an easier and smaller task - just figuring out the version of the "chief" module in the distribution. So it only looks for the first line in the chief .pm file that looks like it contains a $VERSION. By contrast, to create the index of all modules & versions in the distribution, we have to find all 'package' declarations (which Module::Info does a nice job at), and all $VERSIONs within those packages (which it doesn't do yet). Correct me if I'm wrong in my understanding, of course. I'm going to look at Module::Info and try to add a package_version() method or something to it if it's not too terribly hard. -Ken |
|
From: <and...@an...> - 2003-03-31 05:14:05
|
>>>>> On Sun, 30 Mar 2003 15:20:03 -0600, Ken Williams <ke...@ma...> said: > I think MakeMaker is doing an easier and smaller task - just figuring > out the version of the "chief" module in the distribution. So it only > looks for the first line in the chief .pm file that looks like it > contains a $VERSION. Right, it finds only one VERSION per file, but does so for any .pm file you're interested in. > By contrast, to create the index of all modules & versions in the > distribution, we have to find all 'package' declarations (which > Module::Info does a nice job at), and all $VERSIONs within those > packages (which it doesn't do yet). Correct me if I'm wrong in my > understanding, of course. Indeed I correct you: PAUSE took the middle way and in all the years only about 3 people complained: find N package statements in all *.pm files but only one VERSION statement per file. You get an M:N matrix of package name and version numbers, take the max of available version numbers per package. Very trivial and effective. Note that this was defined to be the correct way, even if thinge like package Foo::Bar; $VERSION=42; package Foo::Bar::Baz; $VERSION=123; could surprise somebody who had the weird idea to write such a version hell. We ruled out quite a lot of weird ideas that way. So if you replace PAUSE's heavy weaponry in PAUSE::pmfile::parse_version with plain MakeMaker->parse_version, you're done. -- andreas |
|
From: Ken W. <ke...@ma...> - 2003-04-12 03:55:34
|
On Sunday, March 30, 2003, at 11:13 PM, Andreas J. Koenig wrote: > > Indeed I correct you: PAUSE took the middle way and in all the years > only about 3 people complained: find N package statements in all *.pm > files but only one VERSION statement per file. You get an M:N matrix > of package name and version numbers, take the max of available version > numbers per package. Very trivial and effective. > > Note that this was defined to be the correct way, even if thinge like > > package Foo::Bar; > $VERSION=42; > package Foo::Bar::Baz; > $VERSION=123; > > could surprise somebody who had the weird idea to write such a version > hell. We ruled out quite a lot of weird ideas that way. > > So if you replace PAUSE's heavy weaponry in > PAUSE::pmfile::parse_version with plain MakeMaker->parse_version, > you're done. This is now checked in to CVS. Thanks for the explanation. Note that M::B has its own parse_version() method (extracted from a relatively recent version of MakeMaker), mostly because I arrogantly refuse to actually depend on MakeMaker methods in M::B. ;-) -Ken |
Thanks for helping keep SourceForge clean.
X