Parrot - Config - Base Libraries - Aviary

[Richard Hainsworth]

This post may cover lots of separate issues, but they interact and big 
picture clarity would be useful. Appologies if some issues have been 
resolved and I havent read enough to know better.

Some assumptions:
Parrot will be used in several independent spaces.
    Apart from the perl6 space, it would be ideal as the underlying 
engine for Mozilla scripting.
    (I am unaware about how parrot is regarded in other language 
communities to understand whether it will be develop into an essential 
part of their community - in the same way as parrot is vital to perl6 - 
or whether it is an interesting feasibility project)
Developers in independent spaces may/will not know or care about needs 
in other spaces.
As Parrot evolves there will be increasingly more add-ons / languages

Some problems I have faced:
Getting all the right links right is frustrating
    I was trying to get the SDL examples to work, which required a 
specifically named links to two libraries AND the existence of a ttf 
font in the path.

Configuration
Different problem spaces will require different configurations and 
environments (by which here I take to mean libraries that are developed 
independently from Parrot, eg. Gtk).

I dont think it is possible to decide upon a base set of libraries to 
probe for. What is essential for one problem space is irrelevant for 
another. Compromising and including both is not an elegant solution, 
leading to bloat and increased startup times.

I suggest a configuration file that lists the libraries and dependencies 
to be probed for when parrot starts up. If the configuration file also 
provides helpful error messages when a probe does not work, that will 
aid when dependencies need to be added to a system.

It is possible that each library/module could have its own configuration 
file and initiation, or that a single configuration file is maintained 
for Parrot and when new modules/packages are installed into a local 
system, the configuation file is modified.

To my way of thinking: Windows uses the centralised approach with the 
registry; unixen use both centralised configs in /etc and local ones 
typically as ~/.configurations

Whereas a centralised configuration file means you know where to go to 
do something, they get complex and accrete cruft. A distributed system 
allows software to put stuff all over the place and I sometimes can work 
out where to go or what to change. So there are pluses and minuses to both.

A policy set now by the Parrot development team would be very effective 
in guiding the development of parrot in the way it interacts with its 
environment. The policy does not have to be perfect, just flexible.

Base Libraries

I suggest that NO base libraries are expected by Parrot.

Parrot should only have a pluggable means for testing for libraries via 
the configuration. All libraries would then have to conform to some set 
of standards.

It is for a distribution to include libraries and the appropriate 
configuration file.

A clear policy by the Parrot development team about what a base library 
should look like and where it should be located will allow for 
flexibility and the ability for developers to pick and choose.

Aviary

Parrot needs an analog to CPAN. Since all the variants of Parrot tend to 
get bird-like names, an aviary is where birds are kept.

An effective on-line repository system will enhance the widespread 
utilisation of Parrot

There was/is a long discussion in perl6 land about where CPAN should go 
for perl6. There are several issues (that I have been able to 
disentangle, but there may be more).
a) The structure of the local directory tree where dependencies / 
libraries should reside (this is somewhat OS dependent)
b) The way the components are packaged in the central repository
c) What is packaged in the central library - viz., source or binary
d) resolution of dependency questions (other packages that the target 
package relies on)
e) resolution of versionning questions (which versions of the target 
package exist on the archive)
f) resolution of authorisation questions (is a package safe to use)
g) installation - the process by which a new module/library/package is 
installed locally, and dependencies are identified so that they can be 
installed as well.

I would recommend that the Parrot developers take the opportunity now to 
develop policies about the above as it will encourage diversity of 
development and use.

Respectfully,
Richard