for the drupal.org packaged install profiles, we're leveraging drush_make. the approach we've decided to take is to programatically generate an initial .make file from the packaging script, that just builds core and the profile in question. then drush_make is supposed to take over, discover the .make file in the profile, and finish things up automagically.
however, i don't think we can have the profile in the initial .make file in the way that we thought. the big problem is that we're needing drush_make to download the release we're currently in the middle of building. now i can build the plain tarball of just the profile first, so it's available -- but the project is not published, thus drush_make's standard method of retrieving the update XML for data about the download doesn't work. even if we publish the release node right after we build the plain tarball, and hit the create-release-history script, i think we'll still run into replication problems where the actual tarball won't be there yet for download (i've seen new releases not have their download link work for a few minutes).
what we really need is a way to simply grab the existing plain tarball that we just created, unzip it, and pop it into the profiles folder *during* the make of the initial file, in a place where the auto-discovery of the profile's .make file will still work. but for the life of me i can't figure out how to do it.
any help would be greatly appreciated... :)
marking this critical as it's a major blocker for packaged install profiles on drupal.org, if we are in fact going to use drush_make.
Comments
Comment #1
yhahn commentedI believe you should be able to direct drush_make to package the install profile directly from CVS, bypassing the update XML feed check. Here's an example of the CVS download syntax:
Hope this helps!
Comment #2
robertdouglass commentedHere's another example of tricking dm. The rubik theme on devseed's server doesn't have (or I didn't find) packaging information, so I downloaded it as a library, but told it to stick it in sites/all/themes:
Comment #3
dmitrig01 commentedrobert, you can do this for rubik
However on checking out a release, I think young's solution is the way to go.
Comment #4
Anonymous (not verified) commentedEdit: ignore this and sorry for the noise :(, I thought the CVS root needed to be specified but it's already a default if not overridden.
Comment #5
hunmonk commentedthanks for your tip, yhahn -- it does the trick for me beautifully!
looks like this issue has sufficient information do call it done...