hello world,
drupal.org infrastructure can now be used to host installation profiles:
1) there's a "/contributions/profiles" directory in the contrib repo.
http://cvs.drupal.org/viewcvs/drupal/contributions/profiles/README.txt?v...
2) there's a new Project type, called "Installation profiles":
http://drupal.org/project/Installation+profiles
two critical points i wrote in the README.txt:
a) "At this time, only files ending in .profile or .txt are allowed to be committed, since installation profile maintainers should NOT include the code of the modules that are enabled by their profiles."
b) "In the future, we will have a system where a file in each installation profile directory will define what versions of Drupal core and each contrib module should be packaged with the profile, and the packaging script will generate a single download-able tarball of all the code, and the installation profile. Until that time, the downloadable package for installation profile projects will just contain the .profile and .txt files."
it's likely that somewhere at OSCMS '07 @ Yahoo, a discussion will break out about this topic, including:
- what to name the "packaged collection of a profile, core, and all its contrib modules"?
- how profile maintainers to specify what modules (and versions!) to package with their profile
- etc, etc.
people who care about this debate are encouraged to participate here:
http://groups.drupal.org/distributions
for example:
http://groups.drupal.org/node/2164
http://groups.drupal.org/node/2163
Comments
What about a list of bundled packages?
I was putting a readme in the /modules directory of my profile and I put a list of links to the correct releases that I've tested, and I was thinking, what about something like that for the packaging script? If each directory that was supposed to have modules, themes or translations had a file in that was 'PACKAGE_INCLUDE_FILE' or something similar, that would be parsed by the packaging script and the files listed in it would be fetched from ftp.osuosl.org and expanded and then repackaged with the profile for download.
Admittedly I know nothing of the d.o infrastructure, so I don't know what would offer less overhead, fetching and packaging directly from cvs, or fetching the package over ftp.
-Mike
Will need it
When we automate the creation of full install profiles, then yes, we'll need a bundle list file and a format to parse it with.
What I meant was....
Would it be better to parse a list of CVS directories and tags, i.e.
contributions/modules/calendar DRUPAL-5--1-4contributions/modules/cck DRUPAL-5--1-4
contributions/modules/date DRUPAL-5--1-4
or just list a set of ftp links to already packaged releases:
ftp://ftp.osuosl.org/pub/drupal/files/projects/calendar-5.x-1.4.tar.gzftp://ftp.osuosl.org/pub/drupal/files/projects/cck-5.x-1.4.tar.gz
ftp://ftp.osuosl.org/pub/drupal/files/projects/date-5.x-1.4.tar.gz
Which is better from a load standpoint on the packaging scripts and the d.o infrastructure and even the osuosl.org infrastructure?
Second method would definitely be a lighter load on the cvs, and I would think lighter load overall, except for possibly on ftp.osuosl.org, but then again, how many install profiles do we have, and how often are they gonna need repackaged. This method would seem to me to encourage the use of actual releases instead of changing head branches.[*]
First method though, is probably easier to implement? It seems closer to what the existing packaging script already does, and once again, install profiles aren't going to be a huge load for sometime as there just aren't very many of them.
[*] Should we do some sort of check to force users to use only stable branches, or actual tagged releases in install profiles? What would happen if the user decided to include a module from HEAD in their install profile, and it keeps breaking their install profile or introducing security concerns? Admitedly that really falls to being a resonsible maintainer, but it's something to think about.
-Mikey P
Neither
We have to make things flexible, and also to work OUTSIDE of drupal.org and the OSUOSL. So, the answer is neither.
It would be something like the module name (calendar) and the tag/branch/whatever (DRUPAL-5--1-4).
This a fund raising item that is on my list to get started on soon, and I have tentative agreement from shops to help fund dww to build this right. Now I need dww to get a ballpark estimate together...
well, we might as well start the bikeshed discussion here ;)
I agree with Boris point about it needing to work outside of the Drupal infrastructure, but wouldn't the first idea work for that to some extent. If your rcs repository is vastly different from OSUOSL then it's going to be hard to get this to work...
I think that it would at least need to specify module vs. theme and the tag.
modules/calendar DRUPAL-5--1-4themes/zen DRUPAL-5--1-0
If we don't know module vs. theme then it's possible to have a name collision, right?
The other fun part of the discussion is if it should be in .ini format, .xml, something custom...
Personally I think we should just let dww decide the ini vs. xml vs. custom piece.
Greg
--
Knaddisons Denver Life | mmm Free Range Burritos
knaddison blog | Morris Animal Foundation
as to modules/themes
My thought was to include a modules and themes directory in the profile directory and then putting the file to be parsed within each of those. I did a human parsed version of that with DFC at first because I wanted to make sure that people knew to put the profile specific modules in profiles/dfc/modules and not at /modules and also to leave /sites/all/modules for site specific, and not profile modules.
I suppose it wouldn't hurt to tell it module/theme, but perhaps we should include translation and whatever else we could put in there?
Overall I lean towards a simpler format, and putting a /modules and /themes folder with the files to be parsed and replaced within them.
BTW, are you saying that the FTP links and such would work better, or that fetching from CVS is better?
-Mike
CVS bad
As much as I love CVS, the idea of having install profiles fetch from CVS is a bad idea. We shouldn't rely on everyone having CVS or access to CVS. If we stick to HTTP/FTP, it keeps everything easy.
I think that the APT structure in the Debian world is a good example. It allows you to provide any sources you want, but the name schema is constant. Each source provides a list of packages that it houses.
confused about packaging script
rwohleb - this is something that would run on the drupal.org infrastructure and create a tar.gz file for people to download. It's nothing that will be installed on people's own machines.
Given that, I think your
commentsconcerns go away, right?--
Knaddisons Denver Life | mmm Free Range Burritos
knaddison blog | Morris Animal Foundation
Ahh, yes.
Ahh, yes.
well yes
you can even now create (well kind of) the list to pull from drupal.org programatically, based on the install profile. exactly like apt-get works. the downside is that you need a lot of control at the install site
Yes, look to dww for guidance
I am so not getting into "what should be the format of this manifest" discussion.
So, for modules vs. themes, and potentially "other" (think tinymce javascript), I would just do this (not suggested format:
modules =themes =
other =
No need, again, to use file paths. The package script "knows" what to do with this stuff. There may be need for custom handlers and so on, but we don't need to quite get to that level of complexity yet.