<heavily edited for concision and focus towards goals>
Please note that parts of this are extremely simplified for brevity where I don't think it aids the discussion.
Most languages offer some form of package format you can use (some of them offer several, with varying pros and cons) to package code and release it for others to use on the internet. I find all solutions across every programming language to be lacking in one area or another. To this end, I present an alternative solution for perl packaging that solves the problems that bug me (and others) the most. I assume some familiarity with CPAN, the 'cpan' and 'cpanp' utilities and one of Module::{Build,Install} or EUMM.
A quick introduction to existing solutions
Perl and Python both default to using fully qualified package names (Parent::Child::Class or Parent.Child.Class), where things are generally expected to conform to names on the filesystem (for simplification, I won't discuss including by filename). PHP requires all files to be included by filename though has a similar lookup process when including things with it's library path.
Perl has libraries that perform essentially the same job (if you include the 'make' utility when talking about Module::Install or EUMM). We'll ignore packaging for now and note that the default behaviour is to just drop files into the right place in the perl library hierarchy, mixing everything together.
Python has two options: distutils (ships with python) and setuptools (does not). distutils works much the same as things in perl, setuptools uses a clever 'egg' system that relies on an obscure hack (pth files, for those interested) to drop things into individual per-module-per-version directories.
PHP has two options, PEAR and not using packages at all. The former works reasonably similarly to perl, while the latter doesn't enforce any structure and results in including everything by filename. With some self-discipline and a couple of interesting __autoload hacks, I personally think this is the best system of all. Used badly, it can be the worst system of all, too.
The end user
An end user generally wants a packaging system that causes them as little grief as possible, especially at the beginning of learning to use it, where it remains new and confusing and they haven't found all the quirks and oddities yet. PHP wins here by not having one. Adding code is a simple matter of dropping it into place and including it by filename. There are thousands of examples of PHP code you can just copy and paste into a new PHP file and include without problem and without thinking about it1.If you carry all your deps with you, deployment in PHP is literally FTPing your source tree. This also means PHP code can be checked out of git/hg/darcs/other-vcs directly (or in the case of git, be turned into a submodule etc.) and modified in place if it is so desired (or a bug discovered). There's also absolutely no requirement to be root for any of this and most users are likely to not be root.
Other niggles
1. It would be nice to be able to better distribute non-code assets.
2. It would be nice to do proper versioning (particularly if we got non-code assets sorted)
3. It would be nice to be able to nest packages without having to have ludicrously long names (i.e. all of the parents) and being able to have them in nicely seperated packages.
4. It would be nice if there was closer filename -> package mapping. Most people do it, let's enforce it.
5. It would be nice to more easily introspect what you have installed. With the current botchelism of everything-in-one-place, it's not easy.
The proposition
I propose a new package format called the alpackage (name open to change), which aims to deal with these problems by restructuring how we currently organise packages and providing a simpler way to work with packages that will help attract new users and confuse people a lot less. I've carved things up to allow more flexibility and this is what I've come up with.
Here is a list of goals I wish to achieve with alpaca:
1. Minimal impact on authors.
2. Works with, rather than against MB/MI/EUMM. Alpackages should be installable if you want to.
3. Nesting infinitely, with no requirement to prefix with parental names (none, all, or an unbroken chain that ends with the name of the alpackage itself).
4. Regular perl packages should be supported (through use of a special-cased 'lib' directory) and things should work as normal.
5. Alpackages should be intelligent enough to deal with dependencies. (Yes, I know this is a hard problem)
6. Non-perl content types should be supported.
7. Non-perl content types should be addressable as if they were perl (more below).
8. Versioning should be dealt with better (don't have a good solution yet, please come up with one).
9. Alpackages should automatically scan for alpackages nested within themselves (ad infinitum).
10. Alpackages should not require installation and should be usable directly from a source control checkout.
11. Alpackages should become part of the core in 5.16 if they prove to work well. Perhaps as part of Module::Build and EUMM.
12. Documentation should reflect the simplicity of the overall structure.
13. A cpanp-like utility should be created to deal with installation and dependencies.
14. A corresponding hosting service should be provided for cpan modules turned into git repositories and converted to alpackages to allow people to check modules out of git.
15. Alpackages should be self-hosting (no deps).
The current implementation
Please note the current implementation is up in the air and open to change, particularly on feedback.
foobar/
-- alpackage.pm
-- controller/
-- -- foo.pm
-- template/
-- -- foo.tt
Here we have an alpackage foobar with an alpackage.pm file to configure it, and a directory for each type of content to be distributed in that package (we're using 'controller' and 'template' here).
There are two important things to notice about what we've already declared, firstly that not everything has to be perl code, and secondly that we can split one type of file into multiple content types if we so wish (if this were like catalyst, we would add 'model' and 'view' as well, which could also contain perl files).
Files within the alpackage should be addressable and loadable by a standard format, which is to say foobar::controller::foo or foobar::template::foo (regardless of the fact one is a template). This also enforces filename -> classname conversion (spaces are ignored and any variety of camelcase should be accepted (unless you decided to shoot yourself in the foot and take advantage of case-sensitive filesystems to confuse yourself with two almost-identically-named files)).
Filenames must be relative to the current package, or may optionally include any number of preceding parents (sub-alpackages can appear in the 'alpackage' directory, in which case it may be foo::foobar::controller::foo when the path is foo/alpackage/foobar/controller/foo.pm).
Thoughts?
("What the fuck are you smoking?" does not count as a valid comment, thanks.)
--
1. Not that I think this is a good approach, since most programmers won't even bother to read the code and check whether it's worth using. It's also worth noting that as PHP ships fairly heavy with many libraries by default, code tends to be lumped together rather than being architected properly.
