[pkg-php-pear] composer and debian

[Mathieu Parent]

2013/6/28 andrea rota <a at xelera.eu>:
> hi Mathieu,
>
> with the dependencies for php-composer being reviewed and installed on
> my dev machine for tests, i'm working on php-composer itself: getting
> back to earlier conversations:
>
> On Mon, Jun 24, 2013 at 12:41:32PM +0200, Mathieu Parent wrote:
> [...]
>> > once composer's install task finishes, running bin/composer in the build
>> > directory sources its own classes from src/ and anything else from
>> > vendor/ relative to the build dir (at least, that's my understanding).
>> >
>> > so i'm not sure how to best 'translate' all this into the actual
>> > packaging: i imagine src/, bin/ and doc/ from upstream can be easily
>> > dealt with through dh_install, but i am unsure about the vendor/ folder
>> > that gets created by ``php composer.phar install``: should i just *not*
>> > invoke this in debian/rules (which requires a 'bootstrap' composer.phar
>> > to be downloaded to a tmp dir or to be included as patch into the source
>> > package) and package all the dependencies separately if not already in
>> > Debian, and let dh_phpcomposer list them as dependencies in composer's
>> > own debian/control?
>>
>> Yes, just start with "*not*" running 'php composer.phar install' , and
>> see how it goes.
>
> 'php composer.phar install' also adds into the 'vendor' folder it
> creates some autoloader code, which basically makes available all the
> dependencies installed in a project's 'vendor' folder available to
> any code using them.

Yes. I think this Autoloader part should not be integrated to the
Debian packages, as it is specific to each application. This is a
feature for developers but not for system administrators. Composer is
a "Dependency Manager" and not a package manager. It ease development
but has the same drawbacks of Ant for Java: Every lib is duplicated in
every application.


> in case of system-wide installs (to start with Composer's own library
> code and that of its dependencies), this autoloader code needs to be
> generated in order to make the code installed under
> /usr/share/php/* available.

The composer ".deb" doesn't have to be installed by composer. Why
don't you install it with dh_install?

>
> in a way, upstream addressing their issue #55
> (https://github.com/composer/composer/issues/55) should help here, but
> in the meanwhile i'm reviewing the workarounds mentioned in this thread.
> any further suggestions are welcome.
>
> if/when upstream supports that, Debian packages of composer modules
> should be able to dev-depend on php-composer and use it to install their
> library code in the appropriate locations, i guess through an updated
> dh_phpcomposer, which would be great - but it's early for this.

Yes. But this requires that system-wide installation of Composer
package respect Debian policy. Particularly the section related to
configuration files.

>
> another question i am wondering about is naming of packages: pkg-php-tools
> correctly uses the whole composer package name to infer a debian package
> name - e.g. seld/jsonlint translates to php-seld-jsonlint. this helps to
> differentiate upstram forks, but i'm wondering, in the longer term, how
> to deal with changes of name upstream (e.g. if the 'org' or 'user' part
> of a org/project or user/project composer package name is changed in
> packagist, or if the reference implementation becomes one from a
> different org); moreover, it's probably unusual to have user or org
> names in debian packages: i guess there isn't much that can be done
> about this, but wanted to highlight this side of the composer naming
> game.
>
> (so i should probably rename the two other composer dependency packages
> i'm working on to php-seld-jsonlint, from php-jsonlint, and
> php-justinrainbow-json-schema, from php-json-schema).

There are several mappings:
- Composer name (project/lib) <-> Debian name (php-project-lib):
pkg-php-tools have a bijective algorithm for this one (minus case)
[note 1]
- Composer name <-> path: this is upstream choice [note 2]
- PEAR name (pear.project.org + Some_Name -> php-project-name):
pkg-php-tools algorithm is injective [note 3]
- PEAR name <-> path [note 4]

Also, some packages have a PEAR name and a Composer name.

I'm open to any change, but beware that changing PEAR naming scheme
will bring a transition (for example php5-* to php-* as PECL packages
are really PEAR packages and being PECL is an implementation detail).

This easier for Composer as support for it is very new.


[1]: ... with th drawback you have mentioned, and the risk to have
several projects with the same shortname (using DNS name would have
been better here)
[2]: ... and sometimes it conflicts
[3]: Maybe we should move to something like Fedora
(https://admin.fedoraproject.org/pkgdb/acls/name/php-horde-Horde-Alarm)
or a bijective one: php-pear.horde.org-Horde_Alarm?
[4]: ...and sometimes it conflicts (but mostly when the PEAR name is identical)

> and finally - pkg-php-tools should probably enforce dependency on
> php5-cli *only* (rather than php5 | php5-cli) via substvars when there
> is a 'bin' section in a project's composer.json (this is to avoid
> lintian error php-script-but-no-phpX-cli-dep). if i'm not missing
> something here, i can report a bug for this against pkg-php-tools.

You can file a bug for this.
--
Mathieu