Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Lithium Package and Dependency Management #285

daschl opened this Issue Jan 20, 2012 · 39 comments


None yet

daschl commented Jan 20, 2012

What about using http://packagist.org and composer to manage plugin dependencies? It looks like it is getting more traction and maybe we can integrate it with the Library class too. Also, if people are encouraged to add their plugins there too we have a "central" repository of libraries which can easily be reused.

This is marked as an RFC and it would be cool to get comments both from the core devs and the community to see what they think about it and how they want to use it.



mehlah commented Jan 20, 2012

Had same thoughts few days ago...
What will become li3_lab ?


greut commented Jan 20, 2012

Another one, work in progess: phark


marcghorayeb commented Jan 20, 2012

packagist seems quite nice :)


daschl commented Jan 20, 2012

This doesn't mean that li3_lab is not needed. I packagist is just a repo for composer, so we could also do a composer repo which can be accessed through the lab. Just thinking :)

Because even if we roll our own stuff, we should think about how we can easily integrate other packages (aura components, symfony,..) easily.


mehlah commented Jan 20, 2012

Fair enough :-)


davidpersson commented Jan 20, 2012

Before I begin let me say that I think package managing is complex. That's why I think it's a good idea to leave this to external projects - so we've got more time to focus on the core and nearby plugins. We shouldn't underestimate how much resources maintaining a separate package manager cost. Also I think the composer devs are doing it right in that they make it a cross framework/PHP project.

  1. We should extract any packaging or lab specific code from core into li3_lab. I'm looking at:
  2. We should move the extensions feature from li3_lab into lithium_bin (aka pastium.org) so that lab is solely managing entire packages. lithium_bin will need a few tweaks i.e. it must gain the ability to add further meta data like description, maintainers (plural meaning multiple - with fields name, email and website). It further must be possible to mark a paste as an extension. This should be easy to accomplish but two questions come to my mind: Is lithium_bin not the place for transient pastes? Do we actually need extensions? In general I think it's good if lithium_bin gets more attention it also seems a pretty hackable project, people like to work on.
  3. On the server side we'll reimplement packagist on lab.lithify.me. That means we keep the idea and look of the lab but reuse as much from the packagist code as possible. This could happen by actually pulling in packagist as a library and using/wrapping there classes or writing our own packagist implementation. I didn't look through the packagist code, so someone with knowledge could post her/his estimations about that here. As an alternative I'd also consider using packagist.org but in that case lithium plugins may not get the attention they deserve.
  4. On the client side we'll make the lab command in li3_lab wrap around composer or we decide not to provide any client at all and use composer directly.

Bottom line: We should only deal with packaging as much as needed and make our packaging layer as thin as possible while making the bin much more stronger and moving code to the place they seem to fit best. To "start from scratch" makes no sense to me here but changing the inner workings of the lab does - so maintaining gets easier.

As a sidenote: I actually worked on 1. and 2. In the case of 1. my efforts we're related to how packaging is related to a CI server I was writing. In the case of 2. I got only so far to prepare and update the bin but not actually execute migrating the extension feature. This would've required more discussion which I missed starting until now ;)

Historical sidenote: The lab introduced an equal format as composer does now with their JSON configuration. I still think the lab is great but we just hadn't enough time to improve and battle test it further. I still like the notion of laboratory and thus the title of the lab.


daschl commented Jan 23, 2012

To get a feel for composer and packaging with Lithium, I wrote a short blog post.


After playing with it, I really like how it works and what it does.


mariano commented Jan 23, 2012

I totally agree with @daschl

Composer is getting a lot of heat, and for good reason. Adding li3 to packagist would be recommended


d1rk commented Jan 23, 2012

Sounds like a good idea. One of the current problems of php is packaging. Solving it on a framework level (which is done with a good integration) makes it a good fit. I like davids ideas and thoughts so far. That would make a start easy and realistic.

From a developers point of view, i would like to add my personal needs:

  1. get packages as easy as possible, like described in daschls post
  2. package new packets as easy as possible, like li3_lab allows
  3. package a project, so it can be used as a package, via packagist.org or as a .phar-file
  4. maintain future versions easily and get information about new releases for other packages

That said, i have not dived into php packaging that much, especially because there is no easy way to do so.

For the record, I did a bit of investigation of various specs - although this is by no means exhaustive - and I hope to convince the composer peeps to make some changes to their "spec" so that some things are a bit more flexible than they currently are.

Results are at https://github.com/josegonzalez/dependency-management . Feel free to have a laugh.

As far as keeping the li3_lab around, but having it a host for li3-specific stuff. I also spoke with the composer peeps on the matter. There are potential naming collisions, as people use different names online and in different communities, we might all use the same username. I've proposed some changes to add a community to the name key, but otherwise people will be fighting for their name on the official packagist site, or we'll have to base it on some outside user management tool.

I think the best bet would be to have li3_lab be a packagist alternative for lithium-specific packages. This would be good so that lithium can start guiding composer's development towards being a great PHP solution to dependency management, and not just a good Pear dependency management alternative.


nateabele commented Mar 6, 2012

@josegonzalez What's the status on your "community" amendment to the Composer spec? Did they end up integrating it? If not, is it something we could start moving forward without? For us I don't think it'll be too huge an issue, since most Lithium plugins and such are prefixed.


See the "type" key. We'd want a specific type for lithium. Or two. I think we have libraries and extensions, no? Maybe something like li3-library and li3-extension?


nateabele commented Mar 6, 2012

Extensions are individual classes which typically are (or should be, anyway) distributed in a library, so we can get by on one type value.

li3? The type we use is up to us.


nateabele commented Mar 6, 2012

I think lithium might be better, as it's more explicit, but yeah, that's fine. So what are our next steps? Anything I can help with?

Next steps would be getting all the lithium core libraries to use the spec. I have an existing issue open on composer to add a "support" key, but we can handle that at a later date.

Once the core libraries are updated, we can start pushing this upon all existing extensions - I'm pretty good at opening commits against a large number of repos with mundane stuff like this - which can be ingested by a lithium-specific packagist.


fellars commented Mar 6, 2012

I would love to see this happen.

Question: How does Packagist handle multiple libraries being dependent on different versions of the same package? For example: Library A is dependent on version 1 of Library C (but has not yet upgraded to support version 2), Library B is also dependent on Library C, but only supports version 2+. Can packagist handle this, or is that outside what it can handle?

Sorry for asking here and not on their list; just thought I would ask Lithium crowd since that is what I'm more dependent on at this point :)

@fellars I would ask in #composer-dev on freenode. Not sure how it handles that case, but I think you have a bigger issue ;)

joseym commented May 2, 2012

has there been any update on this - I just integrated composer with a plugin and it went well however composer places the library within its own vendor directory (in my case: joseym). It would be awesome if there were lithium support for this out of the box.

Also very interested to see where this goes! I'm waiting for updates too!


agborkowski commented May 10, 2012

li3 needs this .. :)

joseym commented May 10, 2012

I'm working on li3 composer installer, I started working on it as a library (plugin) but it seems more like something you'd want to keep in the root of your app. Thoughts?

joseym commented May 10, 2012

Ok, after some investigation I found that the installer plugin's location doesn't matter because composer handles all of that behind the scenes.

I have written a composer installer for Lithium. You can now write plugins that's composer.json file defines the type as "li3-libraries" and requires the package "joseym/li3_installer". Any plugins that follow these two requirements will automatically be installed via composer into your libraries directory.

More detailed instructions here: https://github.com/joseym/li3_installer/blob/master/README.md

Very awsome,

I'll have to rethink how I was dealing with my plugin which was trying to
do much of the same things you were.


On Thu, May 10, 2012 at 2:30 PM, Josey Morton <



joseym commented May 10, 2012

@fellars not sure if you've found the answer to you question above.

when you add a required dependency in composer you can specify it's version, tag or commit. Now if your app requires the same package several times (but different versions) i'm not sure how to approach that.


nateabele commented May 11, 2012

@joseym Looks good so far. @savant Any thoughts on li3_installer so far?


mehlah commented May 11, 2012



nateabele commented May 11, 2012

Yeah, that. ;-)

Seems legit. Haven't tested it, but I assume it works if @joseym has been using it.

joseym commented May 14, 2012

I've integrated it with a couple of my plugins. My simple smarty plugin and, as recently as last night, li3_frontender (which actually uses of a lot of other vendor dependencies).

No problems so far.

Seldaek commented Jun 3, 2012

Just FYI "support" key is now available, see http://getcomposer.org/doc/04-schema.md#support for details.

joseym commented Jun 3, 2012

Awesome! Thanks Jordi.

iTapped this message on a tiny iScreen.

On Jun 3, 2012, at 5:44 PM, Jordi Boggiano

Just FYI "support" key is now available, see http://getcomposer.org/doc/04-schema.md#support for details.

Reply to this email directly or view it on GitHub:
#285 (comment)

shama commented Jun 22, 2012

Hey! Can I get a confirmation on the official lithium type for baton (soon composer/installers)? lithium or li3? Reference @joseym 's PR: https://github.com/shama/baton/pull/11

cc @nateabele @gwoo @davidpersson @daschl @josegonzalez @mariano Thanks!


gwoo commented Jun 23, 2012

I like li3.

On Jun 22, 2012, at 12:57 PM, Kyle Robinson Youngreply@reply.github.com wrote:

Hey! Can I get a confirmation on the official lithium type for baton (soon composer/installers)? lithium or li3? Reference @joseym 's PR: https://github.com/shama/baton/pull/11

cc @nateabele @gwoo @davidpersson @daschl @josegonzalez @mariano Thanks!

Reply to this email directly or view it on GitHub:
#285 (comment)

shama commented Jun 24, 2012

@greut Thanks. In the process of being moved to composer/installers#11

patcon commented Jun 25, 2012

As someone who has never in their life used lithium, just want to point out that li3 is pretty unintuitive. Why not just use something that, when perusing a composer.json, many will see and say to themselves "A-ha, the lithium framework"? li3 is a term only insiders will grok :)

Just seems an unnecessary hurdle for understanding something like a composer.json file, which acts as a concise human-readable manifest of app components.

joseym commented Jun 25, 2012

@patcon - very valid point, I say we leave it up to the community as I agree with @josegonzalez's comment here.

That said, could anyone who supports this effort go "vote" on this issue so we can settle on the proper installer type for composer?

joseym commented Mar 24, 2013

@nateabele seems like this could stand to be closed.

@nateabele nateabele closed this Mar 24, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment