[devel] Fwd: [RFC] More core integration

[devel] Fwd: [RFC] More core integration

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 7595 bytes --]

Здравствуйте.
В стандартную поставку перла новой версии (5.10) хотят интегрировать
ещё добрую дюжину новых CPAN модулей.  То есть то, что я от perl-base и
perl-devel отпиливаю, они туда ещё больше подбрасывают.

Идеалы покомпонентной (design by contract), асинхронной разработки
программного обеспечения попираются нынче не каждом шагу.  У кого-нибудь
есть желание пойти туда и громко поругаться?


----- Forwarded message from "Jos I. Boumans" <kane@xs4all net> -----

Date: Wed, 19 Jan 2005 14:25:32 +0100
From: "Jos I. Boumans" <kane@xs4all net>
Subject: [RFC] More core integration
To: Perl 5 Porters <perl5-porters@perl org>
Message-Id: <983D8E42-6A1D-11D9-AC55-000A956B0E06@xs4all net>
X-Mailer: Apple Mail (2.619)

Hi,

As outlined in another thread, I'm currently creating a patchset to add 
CPANPLUS to the core. This has a few consequences however, which would 
necessitate (or prefer) the adoptation of a few other modules. Some of 
them we knew about already, others are here for discussion. I hope this 
will make a fairly conclusive list, so we can keep the overview.

Here's a list of which ones, and the rationale behind them and what 
would happen if we don't:

* Module::CoreList [NEW]
	An 'obvious' choice; Apart from the fact that currently perl core doesn't
 	list what modules are shipped with it in a comprehensible format, this is
	also the one tool (due to lack of more elaborate CPAN index files) which
	modules are part of core perl (especially for older versions of perl).
	By not adding it, CPANPLUS is unable to detect whether a module in an older
	version of perl is actually part of core or not, which is essential for
	dependency resolving and the building of distributions[1].
	It has no dependencies other than Test::More and has shown to pass it's
	tests quite well:
		http://testers.cpan.org/show/Module-CoreList.html

* Module::Build
	An obvious choice; the 'other' CPAN installer. CPANPLUS currently assumes
	Module::Build to be available (it bundles M::B for its CPAN release).
	Would be wise to include this one, as about 10% of CPAN uses this as its
	installer now.
	By not integrating it, we miss out on the tests for CPANPLUS to deal with
	M::B related distributions, but that could be made a 'skiptest', at least
	for now.
	All its dependencies are core perl. It recommends a few non-core modules
	however, including Archive::Tar.

* IPC::Run
	Essential to be able to shell out on all platforms IPC::Open3 is not
	supported on (most notably Win32 and cygwin) to reliably get exit 
	codes
	from the shell and capture the output of the command.
	By not integrating it, CPANPLUS can not function on Win32 and cygwin and
	other platforms not supporting IPC::Open3, which will cause regression
	tests to fail.
	It currently has a bug in its test suite (not the code!) that makes it
	fail on darwin, but a patch for that is already available:
		http://testers.cpan.org/show/IPC-Run.html

	It depends on IO::Tty (which has no more dependencies itself), but IO::Tty
	will not work on Win32 due to lack of header files (works on cygwin ok):
		http://testers.cpan.org/show/IO-Tty.html

	On Win32, for older versions of Socket.pm (only relevant on older perls)
	it depends on Win32::Process. Since we are talking about integrating with
	5.9, this should not be an issue.

* Archive::Tar [NEW]
	To ensure that extraction of modules from CPAN can happen in a predictable
	and portable way, the best thing is to include Archive::Tar in the core as
	well. A::T is a pure perl implementation of tar, which works portably
	across all the platforms it got tested on:
		http://testers.cpan.org/show/Archive-Tar.html

	tar programs are alas not always 'standard' -- not in their options, and
	not in their output. Since CPANPLUS needs to know what files got extracted
	(and more importantly /where/), it needs to parse the output of 
	various
	tar programs to identify these files and locations. On gnu-tars (or gnu-
	compliant ones) this works without fail, but old solaris tars and various
	AIX and third party tars as found on Win32 have their own idea of specs.
	To ensure that CPANPLUS will not fail regression tests due to these flaky
	tar implementations, including Archive::Tar is the safe bet.

	Archive::Tar requires IO::String, which has no more prerequisites, 
	and a
	perfect test result:
		http://testers.cpan.org/show/IO-String.html

	Archive::Tar optionally supports compressed tarballs via IO::Zlib, which
	in turn requires Compress::Zlib or an external gzip binary. CPANPLUS
	requires IO::Zlib to work with the compressed files of CPAN.
	For the same reasons as A::T, the external binary should be avoided,
	and C::Zlib adopted. IO::Zlib itself also has good tests results, 
	both
	tested by itself and Archive::Tar:
		http://testers.cpan.org/show/IO-Zlib.html

	Compress::Zlib is self contained (meaning it bundles all the header files
	required to build) and libz is known to build on at least all the platforms
	perl builds on, but probably more. Currently, there are 2 types of 
	test
	failures reported here:
		http://testers.cpan.org/show/Compress-Zlib.html

		One on Win32 when the build dir has spaces in it, which 
		seems to be a
		test (not code!) bug.
		One on darwin/5.6.0, but since we'll bundle with 5.9, that's 
		not really
		a relevant issue.
	
	An alternative is the pure perl version of Compress::Zlib, aptly 
	named
	Compress::Zlib::Perl -- IO::Zlib would need to be patched to support it,
	but it seems otherwise a viable alternative:
		http://testers.cpan.org/show/Compress-Zlib-Perl.html

* Abstracted out modules from CPANPLUS 0.04x
	Quite a bit of code from CPANPLUS 0.04x got abstracted out into seperate
	(CPAN) modules, to promote code-reuse. This makes the CPANPLUS to be
	integrated quite a bit slimmer, but requires these abstracted out modules
	to be included as well.
	They are all pure-perl are known to work on all platforms except for the
	cases described above. Here's the list:

		* Archive::Extract
			http://testers.cpan.org/show/Archive-Extract.html
		* File::Fetch
			http://testers.cpan.org/show/File-Fetch.html
		* IPC::Cmd
			http://testers.cpan.org/show/IPC-Cmd.html
		* Log::Message
			http://testers.cpan.org/show/Log-Message.html
		* Module::Load
			http://testers.cpan.org/show/Module-Load.html	 * Module::Load::Conditional
			http://testers.cpan.org/show/Module-Load-Conditional.html		* 
Object::Accessor
			http://testers.cpan.org/show/Object-Accessor.html
		* Params::Check
			http://testers.cpan.org/show/Params-Check.html
		* Term::UI
			http://testers.cpan.org/show/Term-UI.html
		* Locale::Maketext::Simple
			http://testers.cpan.org/show/Locale-Maketext-Simple.html


All these modules should be fairly easy to integrate and they are all 
quite small in size. I'm hereby volunteering to (also) integrate the 
modules marked with [NEW], if we can agree this is the way forward :)

Note that where there's a warning about CPANPLUS not working properly, 
we're likely to get reports of failing perl builds on those systems if 
the module is
not included, as CPANPLUS' regression tests do test for these things 
(as opposed to CPAN.pm's tests)

--

Jos Boumans

	"If superman is so smart, why does he wear underpants over his 
	trousers?"

	CPANPLUS	http://cpanplus.sf.net

[1] but that's a discussion for another time; suffice to say that this our
	attempt at making 'NAPC' come true.

----- End forwarded message -----

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Fwd: [RFC] More core integration

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

В Чтв, 20/01/2005 в 12:38 +0300, Alexey Tourbin пишет:
> Здравствуйте.
> В стандартную поставку перла новой версии (5.10) хотят интегрировать
> ещё добрую дюжину новых CPAN модулей.  То есть то, что я от perl-base и
> perl-devel отпиливаю, они туда ещё больше подбрасывают.
> 
> Идеалы покомпонентной (design by contract), асинхронной разработки
> программного обеспечения попираются нынче не каждом шагу.  У кого-нибудь
> есть желание пойти туда и громко поругаться?

Если эти компоненты стабилизировались, давно де-факто входят в
стандартный набор, так ли нужна асинхронность и компонентизация?


[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: Fwd: [RFC] More core integration

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 4348 bytes --]

On Thu, Jan 20, 2005 at 01:14:17PM +0300, Mikhail Zabaluev wrote:
> > Идеалы покомпонентной (design by contract), асинхронной разработки
> > программного обеспечения попираются нынче не каждом шагу.  У кого-нибудь
> > есть желание пойти туда и громко поругаться?
> 
> Если эти компоненты стабилизировались, давно де-факто входят в
> стандартный набор, так ли нужна асинхронность и компонентизация?

Большинство из них не входят в "стандартный набор", но их туда хотят
включить ради абстрактного блага "рядовых пользователей", которые должны
получить "всё в одном".  А разработка этих компонентов ведется отдельно.

Я последнее время слежу за изменениями, которые вносятся в основную
(нестабильную) ветку разработки перла.  Некоторые из этих изменений (т.е.
в заметной степени) сводятся к переливанию из пустого в порожнее,
например так (поиск по слову Upgrade):

Change 21826: Upgrade to Test::Harness 2.38.                        
Change 21871: Upgrade to Digest-MD5 2.33.
Change 21928: Upgrade to CGI.pm 3.01
Change 21935: Upgrade to Time::Local 1.07_94
Change 21991: Upgrade to Encode 1.99.
Change 21996: Upgrade to Switch 2.10, by integrating some changes by
Change 22007: Upgrade to Math::BigInt 1.68.
Change 22021: Upgrade to Test::Harness 2.40.
Change 22029: Upgrade to Getopt::Long 2.34_01
Change 22051: Upgrade to Time::HiRes 1.54
Change 22052: Upgrade to PerlIO::via::QuotedPrint 0.06
Change 22056: Upgrade to Cwd 2.13
Change 22110: Upgrade to Math::BigRat 0.11
Change 22112: Upgrade to Cwd 2.14.
Change 22124: Upgrade to MIME::Base64 2.23.
Change 22126: Upgrade to Locale::Maketext 1.07.
Change 22159: Upgrade to Time::Hires 1.55
Change 22204: Upgrade to Locale::Maketext 1.08.
Change 22325: Upgrade to MIME::Base64 3.00.
Change 22344: Upgrade to prereleases of Math::BigInt 1.70 and
Change 22345: Upgrade to Term::ANSIColor 1.08.
Change 22469: Upgrade to CGI.pm 3.04.
Change 22470: Upgrade to Cwd 2.16
Change 22482: Upgrade to Cwd 2.17.
Change 22621: Upgrade to Unicode 4.0.1
Change 22673: Upgrade to Time::HiRes 1.57.
Change 22674: Upgrade to Digest 1.06.
Change 22675: Upgrade to Digest 1.06.
Change 22680: Upgrade to Time::HiRes 1.59.
Change 22715: Upgrade to FileCache 1.04.
Change 22835: Upgrade to Encode 2.00.
Change 22868: Upgrade to Encode 2.01.
Change 22907: Upgrade to Test::Harness 2.42
Change 22908: Upgrade to Time::Local 1.10.
Change 22909: Upgrade to Unicode::Collate 0.40
Change 22911: Upgrade to Unicode::Normalize 0.30.
Change 22912: Upgrade to Pod::LaTeX 0.57
Change 22914: Upgrade to CGI.pm 3.05
Change 22915: Upgrade to Digest 1.08.
Change 22916: Upgrade to Pod::Perldoc 3.13
Change 22920: Upgrade to Pod::Parser 1.28
Change 22941: Upgrade to I18N::LangTags 0.30.
Change 22942: Upgrade to Locale::Maketext 1.09
Change 22946: Upgrade to I18N::LangTags 0.31.
Change 22964: Upgrade to I18N::LangTags 0.32
Change 22988: Upgrade to Cwd 2.17_03
Change 22991: Upgrade to Cwd 2.18                                   
Change 23024: Upgrade to I18N::LangTags 0.33
Change 23152: Upgrade to Cwd 2.20
Change 23168: Upgrade to File::Spec 0.88.
Change 23171: Upgrade to Math::BigInt v1.71.
Change 23222: Upgrade to Devel::PPPort 3.00.
Change 23223: Upgrade to Devel::PPPort 3.00_01.
Change 23226: Upgrade to Devel::PPPort 3.00_02.
Change 23229: Upgrade to Devel::PPPort 3.00_03.
Change 23232: Upgrade to Time::HiRes 1.61
Change 23234: Upgrade to Devel::PPPort 3.01.
Change 23237: Upgrade to MIME::Base64 3.02.
Change 23238: Upgrade to MIME::Base64 3.03
Change 23248: Upgrade to Cwd 2.21.
Change 23257: Upgrade to version 0.42.
Change 23258: Upgrade to Encode 2.02
Change 23280: Upgrade to Devel::PPPort 3.02.
Change 23282: Upgrade to Devel::PPPort 3.03.
Change 23322: Upgrade to Time::HiRes 1.63.
Change 23329: Upgrade to Time::HiRes 1.65.
Change 23330: Upgrade to MIME::Base64 3.05.
Change 23380: Upgrade to Encode 2.04.
Change 23384: Upgrade to Encode 2.05
Change 23417: Upgrade to Encode 2.07
Change 23421: Upgrade to Encode 2.08.
Change 23566: Upgrade to Test::Simple 0.53
Change 23620: Upgrade to Term::ANSIColor 1.09
Change 23624: Upgrade to Encode 2.09
Change 23630: Upgrade to perldoc 3.14
Change 23653: Upgrade to ExtUtils::MakeMaker 6.25
Change 23654: Upgrade to Test::Simple 0.54
Change 23700: Upgrade to Devel::PPPort 3.04

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: Fwd: [RFC] More core integration

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

В Чтв, 20/01/2005 в 13:38 +0300, Alexey Tourbin пишет:
> On Thu, Jan 20, 2005 at 01:14:17PM +0300, Mikhail Zabaluev wrote:
> > > Идеалы покомпонентной (design by contract), асинхронной разработки
> > > программного обеспечения попираются нынче не каждом шагу.  У кого-нибудь
> > > есть желание пойти туда и громко поругаться?
> > 
> > Если эти компоненты стабилизировались, давно де-факто входят в
> > стандартный набор, так ли нужна асинхронность и компонентизация?
> 
> Большинство из них не входят в "стандартный набор", но их туда хотят
> включить ради абстрактного блага "рядовых пользователей", которые должны
> получить "всё в одном".  А разработка этих компонентов ведется отдельно.
> 
> Я последнее время слежу за изменениями, которые вносятся в основную
> (нестабильную) ветку разработки перла.  Некоторые из этих изменений (т.е.
> в заметной степени) сводятся к переливанию из пустого в порожнее,
> например так (поиск по слову Upgrade):

Так значит, они делают часть работы за вас :)
Вопрос только в том, возникает ли между релизами perl нужда обновлять
эти модули.


[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: Fwd: [RFC] More core integration

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

On Thu, Jan 20, 2005 at 02:18:59PM +0300, Mikhail Zabaluev wrote:
> > Я последнее время слежу за изменениями, которые вносятся в основную
> > (нестабильную) ветку разработки перла.  Некоторые из этих изменений (т.е.
> > в заметной степени) сводятся к переливанию из пустого в порожнее,
> > например так (поиск по слову Upgrade):
> 
> Так значит, они делают часть работы за вас :)

Хм.  В этом есть резон. :)

С другой стороны, я могу критически оценивать ту часть работы, которую они
проделали за меня.  То есть это во многом "философский" (ой блин) вопрос --
подумать самому, как лучше "распилить" перл, или же за тебя уже
подумали и прислали нечто нераспливаемое на блюдечке с голубой каёмочкой
(и 10-метровый тарболл -- это далеко не предел).

Being more specific and concrete, я не думаю, что CPANPLUS и
Module::Build, а также всё, что они за собой вытягивают, должно входить
в perl core.

> Вопрос только в том, возникает ли между релизами perl нужда обновлять
> эти модули.

Это в значительной степени выявляется регулярными автоматическими
пересборками (regression testing), т.к. `make test' выполняется по
умолчанию.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]