patcon · June 19, 2012 19:43
diff --git a/gistfile1.txt b/gistfile1.txt
 patcon:
 yo shama, you're an effing hero of a maintainer. RobLoach and I are lauding you in #drupal-contribute :)
 3:17ppatcon:
 thanks man
 3:19ppatcon:
 Relevant: https://github.com/shama/baton/issues/5#issuecomment-6433735
 3:24pSeldaek:
 shama: I'm not sure if the target-dir hack you pulled is a good idea
 3:24pSeldaek:
 the purpose of the feature was somewhat different
 3:24pSeldaek:
 and I'm not sure how it helps anyway to have those variables, if they only copy the package name/vendor/type
 3:25pSeldaek:
 and especially, I don't really see how it helps with the drupal custom sites thing
 3:25pSeldaek:
 but maybe I missed something there
 3:25pSeldaek:
 shama: that said, as I wrote on twitter, I think that's a very cool idea overall (baton)
 3:28pbeberlei:
 couldnt one just use the "extra" key for this?
 3:28pbeberlei:
 and then do something in the installer?
 3:29pasm89:
 baton.json for your specific needs? ;)
 3:36pSeldaek:
 beberlei: yeah, extra is fine IMO, but I think this info doesn't belong anyway in the composer.json of the package since it is defining where it'll be installed. It should be in the consumer composer.json /cc patcon
 3:38pasm89:
 Seldaek: why should it even be in composer.json?
 3:39pSeldaek:
 asm89: that doesn't matter so much.. baton is just a composer "plugin" of sorts, so as such keeping the info in the composer.json sort of makes sense
 3:39pSeldaek:
 unless it grows to have a billion options
 3:39pasm89:
 sure
 3:40pasm89:
 but i guess configuring custom install options for packages will end up with some key-value thing
 3:40pasm89:
 before you know it gets big of course ;)
 3:40pasm89:
 apart from all that, big hooray for baton, saw it earlier today, awesome stuff
 3:41p
 RobLoach joined the chat room.
 3:41pRobLoach:
 Oh, didn't know this channel existed.
 3:42ppatcon:
 RobLoach: I'll copy you the scrollback :)
 3:42pshama:
 Thanks! :) I didn't really anticipate this response. I was building an installer for CakePHP and Composer made it so easy, so I figured why not add more frameworks. Seldaek: How would a consumer customize a package install path? I thought it was a good addition because of the wild differences between frameworks.
 3:43p
 OSInet joined the chat room.
 3:43p
 OSInet left the chat room.
 3:44pshama:
 If target-dir isn't a good spot for this then I'll move it to extras though
 3:45pRobLoach:
 Extras seems like an appropriate place for it. So far the only usage of target-dir I've seen is with Symfony.
 3:47pRobLoach:
 baton.json doesn't really make sense when it could easily just make use of extras.
 3:47pshama:
 np any opinion on a key? customInstallPath ?
 3:47pshama:
 Yes I agree... I would like to keep it all in composer.json
 3:47pRobLoach:
 "extras": {"baton": { "path": "my/path"}} ?
 3:48pRobLoach:
 That would allow us to add additonal baton-related configurations.
 3:49pasm89:
 RobLoach: "package": "custom/path" no?
 3:49pasm89:
 sorry i wasn't familiar with the extra key, makes total sense
 3:50pRobLoach:
 https://github.com/composer/composer/blob/master/doc/04-schema.md#extra
 3:50pshama:
 That looks good RobLoach
 3:50pRobLoach:
 I wasn't familiar with it either, but it makes sense for a Composer CustomInstaller.
 3:51pSeldaek:
 RobLoach: you didn't know this channel? I'd have sworn you were here before :p
 3:51pRobLoach:
 Seldaek: Haha, I recently changed my znc configuration, so I might've accidently switched to #composer rather than #composer-dev.
 3:53ppatcon:
 RobLoach: no way. didn't even know #composer was a thing. this has been like a gift exchange of ignorances
 3:53pshama:
 Seldaek: Let me know what you think about putting a custom path in extras. I would like to do it the Composer way. Which is why I also used 4 spaces for indent (among other code styles) where I'm used to the CakePHP style ;)
 3:53pSeldaek:
 shama: my point is, if the package itself defines where it's installed, how could you as a user define that you want it in drupal's sites/all/* or sites/foo.com/*?
 3:54pRobLoach:
 patcon: Another issue with using this for Drupal though is that Drupal's versioning is somewhat problematic. "7.x-1.3" makes absolutely no sense when Composer reads in the tags for version information :-( . We might want to make a DrupalRepository, or something.
 3:54pSeldaek:
 shama: as for the name, whatever you do, we try to stick to foo-bar for naming of composer.json keys
 3:55ppatcon:
 RobLoach++
 3:55pSeldaek:
 RobLoach: well, this is.. sort of bullshit :)
 3:55pSeldaek:
 I get the point, but semver sounds more sensible to me
 3:55p
 rdohms left the chat room. (Remote host closed the connection)
 3:55pRobLoach:
 Seldaek: But semver just makes too much sense for Drupal people to understand!
 3:56p
 rdohms joined the chat room.
 3:56pSeldaek:
 and a custom repo wouldn't really save you, if composer doesn't understand your versions it will blow up
 3:56pRobLoach:
 Ah, hmm
 3:56ppatcon:
 Seldaek: we just need baby-steps. composer integration is hard enough without insisting it come with a whole new format for versioning :)
 3:56pSeldaek:
 you'd need a custom version parser and custom comparison logic etc, it's not impossible if you build it into drupal and extend stuff, but it's not trivial either
 3:57pSeldaek:
 patcon: I get that, but maybe you should drop it for now and focus on the whole symfony components, twig, monolog, and whatnot :)
 3:57ppatcon:
 Seldaek: any chance that versioning could be pluggable? or that we could somehow rewrite how composer reads it?
 3:57ppatcon:
 ah
 3:57pSeldaek:
 you already have a shitload of stuff on your plate:)
 3:57pRobLoach:
 Seldaek: Oh! Monolog, I forgot I had a patch for that one :-) .
 4:00pSeldaek:
 RobLoach: I discussed it with Crell and FGM (OSInet dude?) in paris, seemed doabl
 4:00p
 rdohms left the chat room. (Ping timeout: 245 seconds)
 4:02pSeldaek:
 patcon: I take it you saw my answer preceding your question? right now it'd require some work in composer, and then a lot of work on your end..
 4:02pRobLoach:
 Everything is doable :-) .
 4:04ppatcon:
 Seldaek: ah sorry, read but was impolitely didn't respond. to be honest, i'm more involved in drupal build automation projects now. really interested in composer in that sense, but haven't jumped in yet as RobLoach has :)
 4:04ppatcon:
 ie. would love to take a stab at those thing, but not sure how soon it will be
 4:10pSeldaek:
 well, would be nice, but no rush on my end.. enough problems as it is :)
 4:11pRobLoach:
 Oh no, all this stuff is awesome, it's Drupal that has a lot of catching up to do lol
 4:11ppatcon:
 deeefinitely what RobLoach said :)
 4:19p
 inspiran joined the chat room.
 4:26p
 Grayside joined the chat room.
 4:30pSeldaek:
 shama: I think you'll hit a problem because the main composer config isn't available to custom installers (yet, there's an issue for it)
 4:34pshama:
 Seldaek: I was afraid of that. I need an excuse to jump more into Composer anyways, heh.
 4:36ppatcon:
 Relevant: https://github.com/composer/composer/issues/672
 4:43pshama:
 It's not a big issue though as most frameworks are pretty strict where things go. My biggest hope is just to entice each framework package author to start submitting to packagist and avoid more spin offs. Loosely coupled frameworks are really nice.
 4:43pshama:
 Thanks patcon! Bookmarked
 4:44ppatcon:
 shama: no problem, but pssst. there's a link down at the bottom so you can get github notifications without commenting yet. only saying because i just found it and used it for the first right now :)
 4:45pshama:
 ah thanks... a little better than my old fashion bookmarks :)
 4:46ppatcon:
 shama: and not sure if I'm understanding you correctly, but at least with drupal, the community is centered on drupal.org, and any push to move it to another third party site would be met with a bit of resistance
 4:47pSeldaek:
 patcon: for something the size of drupal, and given the amount of modules, I think it's ok to run your own repo for modules
 4:47ppatcon:
 shama: not sure where I stand, but i think uptake would be slowed in many cases if you focused on developing with the expectation that packagist would be the go-to repository
 4:47pSeldaek:
 but it would give you access to the packagist ecosystem too, which is great
 4:47pshama:
 Yes drupal I wouldn't consider a spin off ;)
 4:49ppatcon:
 Seldaek: true. just saying, even i don't want to be pushed into using packagist.org yet, and i'm pretty gung ho about composer
	patcon:
	yo shama, you're an effing hero of a maintainer. RobLoach and I are lauding you in #drupal-contribute :)
	3:17ppatcon:
	thanks man
	3:19ppatcon:
	Relevant: https://github.com/shama/baton/issues/5#issuecomment-6433735
	3:24pSeldaek:
	shama: I'm not sure if the target-dir hack you pulled is a good idea
	3:24pSeldaek:
	the purpose of the feature was somewhat different
	3:24pSeldaek:
	and I'm not sure how it helps anyway to have those variables, if they only copy the package name/vendor/type
	3:25pSeldaek:
	and especially, I don't really see how it helps with the drupal custom sites thing
	3:25pSeldaek:
	but maybe I missed something there
	3:25pSeldaek:
	shama: that said, as I wrote on twitter, I think that's a very cool idea overall (baton)
	3:28pbeberlei:
	couldnt one just use the "extra" key for this?
	3:28pbeberlei:
	and then do something in the installer?
	3:29pasm89:
	baton.json for your specific needs? ;)
	3:36pSeldaek:
	beberlei: yeah, extra is fine IMO, but I think this info doesn't belong anyway in the composer.json of the package since it is defining where it'll be installed. It should be in the consumer composer.json /cc patcon
	3:38pasm89:
	Seldaek: why should it even be in composer.json?
	3:39pSeldaek:
	asm89: that doesn't matter so much.. baton is just a composer "plugin" of sorts, so as such keeping the info in the composer.json sort of makes sense
	3:39pSeldaek:
	unless it grows to have a billion options
	3:39pasm89:
	sure
	3:40pasm89:
	but i guess configuring custom install options for packages will end up with some key-value thing
	3:40pasm89:
	before you know it gets big of course ;)
	3:40pasm89:
	apart from all that, big hooray for baton, saw it earlier today, awesome stuff
	3:41p
	RobLoach joined the chat room.
	3:41pRobLoach:
	Oh, didn't know this channel existed.
	3:42ppatcon:
	RobLoach: I'll copy you the scrollback :)
	3:42pshama:
	Thanks! :) I didn't really anticipate this response. I was building an installer for CakePHP and Composer made it so easy, so I figured why not add more frameworks. Seldaek: How would a consumer customize a package install path? I thought it was a good addition because of the wild differences between frameworks.
	3:43p
	OSInet joined the chat room.
	3:43p
	OSInet left the chat room.
	3:44pshama:
	If target-dir isn't a good spot for this then I'll move it to extras though
	3:45pRobLoach:
	Extras seems like an appropriate place for it. So far the only usage of target-dir I've seen is with Symfony.
	3:47pRobLoach:
	baton.json doesn't really make sense when it could easily just make use of extras.
	3:47pshama:
	np any opinion on a key? customInstallPath ?
	3:47pshama:
	Yes I agree... I would like to keep it all in composer.json
	3:47pRobLoach:
	"extras": {"baton": { "path": "my/path"}} ?
	3:48pRobLoach:
	That would allow us to add additonal baton-related configurations.
	3:49pasm89:
	RobLoach: "package": "custom/path" no?
	3:49pasm89:
	sorry i wasn't familiar with the extra key, makes total sense
	3:50pRobLoach:
	https://github.com/composer/composer/blob/master/doc/04-schema.md#extra
	3:50pshama:
	That looks good RobLoach
	3:50pRobLoach:
	I wasn't familiar with it either, but it makes sense for a Composer CustomInstaller.
	3:51pSeldaek:
	RobLoach: you didn't know this channel? I'd have sworn you were here before :p
	3:51pRobLoach:
	Seldaek: Haha, I recently changed my znc configuration, so I might've accidently switched to #composer rather than #composer-dev.
	3:53ppatcon:
	RobLoach: no way. didn't even know #composer was a thing. this has been like a gift exchange of ignorances
	3:53pshama:
	Seldaek: Let me know what you think about putting a custom path in extras. I would like to do it the Composer way. Which is why I also used 4 spaces for indent (among other code styles) where I'm used to the CakePHP style ;)
	3:53pSeldaek:
	shama: my point is, if the package itself defines where it's installed, how could you as a user define that you want it in drupal's sites/all/* or sites/foo.com/*?
	3:54pRobLoach:
	patcon: Another issue with using this for Drupal though is that Drupal's versioning is somewhat problematic. "7.x-1.3" makes absolutely no sense when Composer reads in the tags for version information :-( . We might want to make a DrupalRepository, or something.
	3:54pSeldaek:
	shama: as for the name, whatever you do, we try to stick to foo-bar for naming of composer.json keys
	3:55ppatcon:
	RobLoach++
	3:55pSeldaek:
	RobLoach: well, this is.. sort of bullshit :)
	3:55pSeldaek:
	I get the point, but semver sounds more sensible to me
	3:55p
	rdohms left the chat room. (Remote host closed the connection)
	3:55pRobLoach:
	Seldaek: But semver just makes too much sense for Drupal people to understand!
	3:56p
	rdohms joined the chat room.
	3:56pSeldaek:
	and a custom repo wouldn't really save you, if composer doesn't understand your versions it will blow up
	3:56pRobLoach:
	Ah, hmm
	3:56ppatcon:
	Seldaek: we just need baby-steps. composer integration is hard enough without insisting it come with a whole new format for versioning :)
	3:56pSeldaek:
	you'd need a custom version parser and custom comparison logic etc, it's not impossible if you build it into drupal and extend stuff, but it's not trivial either
	3:57pSeldaek:
	patcon: I get that, but maybe you should drop it for now and focus on the whole symfony components, twig, monolog, and whatnot :)
	3:57ppatcon:
	Seldaek: any chance that versioning could be pluggable? or that we could somehow rewrite how composer reads it?
	3:57ppatcon:
	ah
	3:57pSeldaek:
	you already have a shitload of stuff on your plate:)
	3:57pRobLoach:
	Seldaek: Oh! Monolog, I forgot I had a patch for that one :-) .
	4:00pSeldaek:
	RobLoach: I discussed it with Crell and FGM (OSInet dude?) in paris, seemed doabl
	4:00p
	rdohms left the chat room. (Ping timeout: 245 seconds)
	4:02pSeldaek:
	patcon: I take it you saw my answer preceding your question? right now it'd require some work in composer, and then a lot of work on your end..
	4:02pRobLoach:
	Everything is doable :-) .
	4:04ppatcon:
	Seldaek: ah sorry, read but was impolitely didn't respond. to be honest, i'm more involved in drupal build automation projects now. really interested in composer in that sense, but haven't jumped in yet as RobLoach has :)
	4:04ppatcon:
	ie. would love to take a stab at those thing, but not sure how soon it will be
	4:10pSeldaek:
	well, would be nice, but no rush on my end.. enough problems as it is :)
	4:11pRobLoach:
	Oh no, all this stuff is awesome, it's Drupal that has a lot of catching up to do lol
	4:11ppatcon:
	deeefinitely what RobLoach said :)
	4:19p
	inspiran joined the chat room.
	4:26p
	Grayside joined the chat room.
	4:30pSeldaek:
	shama: I think you'll hit a problem because the main composer config isn't available to custom installers (yet, there's an issue for it)
	4:34pshama:
	Seldaek: I was afraid of that. I need an excuse to jump more into Composer anyways, heh.
	4:36ppatcon:
	Relevant: https://github.com/composer/composer/issues/672
	4:43pshama:
	It's not a big issue though as most frameworks are pretty strict where things go. My biggest hope is just to entice each framework package author to start submitting to packagist and avoid more spin offs. Loosely coupled frameworks are really nice.
	4:43pshama:
	Thanks patcon! Bookmarked
	4:44ppatcon:
	shama: no problem, but pssst. there's a link down at the bottom so you can get github notifications without commenting yet. only saying because i just found it and used it for the first right now :)
	4:45pshama:
	ah thanks... a little better than my old fashion bookmarks :)
	4:46ppatcon:
	shama: and not sure if I'm understanding you correctly, but at least with drupal, the community is centered on drupal.org, and any push to move it to another third party site would be met with a bit of resistance
	4:47pSeldaek:
	patcon: for something the size of drupal, and given the amount of modules, I think it's ok to run your own repo for modules
	4:47ppatcon:
	shama: not sure where I stand, but i think uptake would be slowed in many cases if you focused on developing with the expectation that packagist would be the go-to repository
	4:47pSeldaek:
	but it would give you access to the packagist ecosystem too, which is great
	4:47pshama:
	Yes drupal I wouldn't consider a spin off ;)
	4:49ppatcon:
	Seldaek: true. just saying, even i don't want to be pushed into using packagist.org yet, and i'm pretty gung ho about composer