Now that drupal has install profiles there is quite a bit of talk about drupal distributions. Just like there are modules and themes there should be a way for drupal to handle distributions.

Comments

dww’s picture

Project: Project » Drupal.org site moderators
Version: 5.x-1.x-dev »
Component: Projects » Site organization

actually, this has nothing to do with project.module per se (at least not yet). all we'd really need (at first) is a new top-level project vocabulary term called "Distribution" or something, which then became a valid project type.

however, there are probably other changes we'd need down the road, but the basic support doesn't require any modifications to any code, just configuration.

p.s. i could have sworn there was already an issue open about this, but a quick search didn't find it. maybe i'm just thinking of the numerous email threads on various lists, but none of them actually made it into the issue queue. however, if someone else finds an earlier issue, please mark this one duplicate. thanks.

RobRoy’s picture

Again, we need to clarify Installation Profiles from Distributions. So would a Corporate distribution hosted on d.o package the corporate.profile Installation Profile along with TinyMCE, Views, etc. into one nice zip?

I think we'll just be hosting Installation Profiles to start off and need that separation so we can then have blogger.profile, corporate.profile, etc. on d.o and post issues / feature requests to them separate from included contrib modules.

dww’s picture

yeah, we could start with "Install profiles" as the project type, and setup "/contributions/install_profiles" in the CVS repo. then, /contributions/install_profiles/blogger would be a directory containing anything related to this install profile (certainly the .profile file, if that's what it's called, a README.txt, and a list of contribs or something).

later, we can consider adding support for full distributions, that specify what contribs to be packaged up.

RobRoy’s picture

Yeah, I'm all for that. The implementation looks good, so you've got my +1. Now that 5.0 is out it would be nice to give the install profiles functionality some public consumption.

webchick’s picture

Let's keep the directory name 'profiles' to match what's in core, like we do for 'modules' and 'themes'.

There was a _huge_ discussion on this on the infra list a few months ago. To sum up, people are very nervous about providing downloads of distributions from drupal.org because of the fear that people won't maintain their distros, they fall behind in security updates, and Drupal gets a reputation for being insecure. So, if there's a way to build into the packaging scripts that _only_ .profile files are allowed in this directory, that would help mitigate these concerns.

gusaus’s picture

Is there now a clearly (or somewhat) defined distinction between install profiles vs distributions? This was (one of many) discussion threads:
http://groups.drupal.org/node/2164

Great to see some movement with this!

merlinofchaos’s picture

IMO, the files are basically pointless if the user downloading the profile has to go on a scavenger hunt for all the modules. There needs to be a way to get the whole package, even if it's because the system collects all the modules in the profile and puts them in a tar for you.

kbahey’s picture

It is high time we rename this to the proper name "install profiles", both in core and in the CVS directories.

We already have a profile module that is in the handbook in several places, and don't want confusion, let alone lots of support requests, over that.

RobRoy’s picture

Yeah, we really only need .profile and .TXT in there for now. And "profiles" is more consistent. I was thinking install_profiles would be less confusing since we already have a profiles module, but it's not a huge deal.

Later on we could just have a neat packaging script that automatically pulls Drupal core, our .profile and specific contrib modules specified in our .profile's profilename_profile_modules(). This could get us a long way towards "Distributions" (up until people start hacking core) and we wouldn't need to worry about security updates as they would be automatically included since we're just pulling the latest core/contrib release.

RobRoy’s picture

Title: Drupal Distributions » Drupal Installation Profiles & Distributions

My comment was written in reply to webchick's #5. You guys snuck in before me. ;)

When I was following the mailing list, it seemed "Installation Profiles" was the accepted term and proper grammar as opposed to "Install Profiles" when talking about the .profile files. So let's stick with the former when talking about the .profile files in text and I guess CVS as well.

But, the packaged up .profile, core, and contrib modules is a "Distribution" to me. So the links to download those packages should be entitled Distributions, whereas the project pages to post issues/feature requests for a specific .profile should be in regards to an Installation Profile.

And I agree with merlin that we should only start pushing this to the forefront once we have a nice packaging script to create Distributions. But, I think creating project pages for installation profiles could be a nice intermediary step to allow us to start testing Installation Profiles and getting them to a usable point.

mfer’s picture

When I was looking into this I was surprised that I couldn't find an issue on this already.

I can see this as two parts but I think distributions should be the end goal. Though, to start with installation profiles could be a good thing.

I think it would be good for the distributions to have 2 things to them. An installation profile and a file that tells it what version of core and contrib modules to include. Then have a script build the distribution.

Distribution maintainers should be like module maintainers and be expected to keep up on them, handle issues, and pass them on to someone else if they are going to abandon them unless something supersedes them.

sepeck’s picture

a few complications. some modules rely on users to download code from other sites because it is not gpl or not our project (TinyMCE, FCKEditor). So the general consensues was let's start with install profiles and see what we learn from them.

I personally see distributions as a service offering for others (your ISP, your development/design/services company. I think that before we allow any actual distributions to be hosted on drupal.org we need to learn from install profiles first. Then we need to set some very high standards about who will be maintaining them and their responsibilities. Others disagreed but several people had comments like just because I put a distro together doesn't mean I want to maintain it. Well I certainly don't want to have insecure distro's maintained off Drupal.org either.

So a good start would be maintaining a central repo of install profiles. We can learn from it and incorporate improvements into the system for 6.0.

Boris Mann’s picture

Hopping on to follow along. Agreed on many of the points here, including the last: I'm in the "show me" school....if people have install profiles / distributions....show 'em. We've got one in our public SVN repo. I haven't seen / heard a lot of feedback on others "in the wild". We can tackle this on d.o. once a couple of people have something to show.

And, of course, agreed on packaging scripts re:modules. Some of the better install profiles might include a script to grab the latest version of tinymce and "do the right thing".

webchick’s picture

@Boris, One of the key advantages of providing a central repository of installation profiles here on drupal.org is that we can start to see in one place what types of things are being built. You have a couple in SVN, I have a couple on my local box I'm tinkering with, a couple other people are making some, etc. There's a good chance that two or more of us are building the exact same thing in isolation, and we could instead be collaborating on a profile together to build the ultimate "Drupal for X task." The only way for this to happen is if the profiles are stored centrally at drupal.org, and you can create a project/issue tracker for them, and thus get a community going around them.

@everyone else: Notice I said installation profile (the .profile file), not distribution (a .zip of all the various modules + Drupal). There is still heavy contention over whether or not Drupal.org should provide distributions.

mfer’s picture

+1 on adding Installation Profiles to d.o.

This seems like it's really two issues. I don't think I have read anything against having Installation Profiles. I think we should go after them.

The distributions is something that is a little tougher to get into. Is this something d.o. should host? Is it something, like linux, that should be maintained outside the core site? It's a tough question. But, one that should be debated separate from Installation Profiles.

kbahey’s picture

+1 for install profiles on d.o.

Centralizing the Drupal "add ons" has proven its success and is a key ingredient in the growth of the project and the community. If we do not do that, it will be fragmented, and had to find, and hence would not have the same impact as (say) the myriad of modules on d.o

dww’s picture

Title: Drupal Installation Profiles & Distributions » Hosting installation profiles on d.o

ok then, let's leave this issue to focus on what we can all agree on, as i suggested above. ;)

1) new top-level "Project type" taxonomy term
2) new directory in CVS repo
3) the crowds go wild. ;)

so, we just need names for #1 and #2, and the proverbial +1 for a seriously Big Cheese(Tm) around here (Dries and/or Killes).

it's still a tragedy that "profile" got overloaded like this, and in the name of "it's too late now to change it", we're stuck with an overloaded, confusing term. :( alas. however, at this point, it'd be worse if the project stuff on d.o didn't match the files in core. so, for better (no) or worse (yes), these are going to be called ".profile" files. However, I think the directory and project type can still have "Install" or "Installation" in there to somewhat alleviate the pain.

"Installation profiles" is better english
"Install profiles" is easier to type

so, it seems we have only 3 viable choices:
a) "Installation profiles" + "installation_profiles"
b) "Install profiles" + "install_profiles"
c) "Profiles" + "profiles"

i think it'd probably vote for (b), but don't care that much. if we decide in the next 24 hours, i could help set this up, otherwise y'all are on your own until the end of february. ;)

webchick’s picture

d) "Installation profiles" + "profiles"

(assuming the first is the term and the second is the directory in CVS ... I'm pretty adamant about the second matching what's in core; the other one not as much, but "installation profiles" is correct English.)

A README.txt in the root of the profiles directory in CVS could clarify that these refer to Drupal installation profiles and not anything to do with the profile module, if it becomes an issue.

mfer’s picture

+1 on option D

RobRoy’s picture

Yeah, +1 on D. If you're mucking around in CVS you should be able to figure out what's actually in the "profiles" directory. Thanks Derek.

gusaus’s picture

Seems like option 'd' would be a good middle ground - whatever it takes to get 'em supported. Once set up, I'm thinking a lot of the relevant Drupal working/learning groups will be good places for collaboration, learning, and working on/resolving some of the issues that have been discussed.

Thanks Derek for pushing this forward!

dww’s picture

crap, i knew someone would want that option, but i didn't want to mention it. thanks to how many people used to screw this up, cvs.module now validates that the first part of the cvs directory field matches the top-level project term (project type):

http://drupal.org/admin/project/cvs-settings

[X] Validate CVS directory using Project type
If this box is checked, the first element of the path specified in the CVS directory field must match the selected Project type for project nodes. Note: this is a case insensitive comparison, and spaces in the Project type field will be converted to hypens ('-') for the purpose of the comparison.

so, either:

1) we use the same names for both (i.e. "D" is invalid).
2) we turn off this setting (to the detriment of accuracy in general)
3) someone (not me) gets to roll a patch to make this setting not a single checkbox, but a full table of "term vs. directory" mappings. :(

all those "+1 for D" votes must vote again. ;)

sorry,
-derek

p.s. hehe, and therefore, for A or B, the cvs dir should be "installation-profiles" or "install-profiles" (which is consistent with "theme-engines"). ;)

RobRoy’s picture

Dude, the CVS top-level directory name is not a huge deal. Having it be named installation_profiles is even more explicit. The only thing we lose is 2 seconds of our day spent typing "installation_". Go with "Installation Profiles" and "installation_profiles". It's consistent, not confusing, and works within the current infrastructure. +1

Dries’s picture

"profiles" is a much nicer directory name, and more consistent with the current structure. -1 on "install_profiles".

Either way, keep the flow of thoughts comming. I'll work my way through the list, and implement this on drupal.org. Please, don't move this forward without my blessing. Thanks! :-)

webchick’s picture

Crushed about my wonderful option D not being an option after all, I inquired as to the nature of this validating that project module's doing.

Basically, before this was added in, people were doing silly things like uploading modules to the root CVS directory and whatnot. It got to be really annoying to clean these out, so killes asked that the validation go in; now, they can only upload to the directory that matches the top-level term they chose. This change was months and months ago, so is not likely to be rolled back (nor should it; sounds handy).

However, tying directories to taxonomy term names seems very fragile, so ultimately de-coupling the two (aka option 3) is the best solution. dww claims he can have something together in 10 mins. ;)

dww’s picture

http://drupal.org/node/114356 (my local D5 test site wasn't cvs.module enabled, so testing took 10 more minutes that i had hoped) ;)

dww’s picture

Assigned: Unassigned » dww
Status: Active » Needs review

my patch is now installed on s.d.o, and i added the new project type there. behold:

http://scratch.drupal.org/project
http://scratch.drupal.org/project/Installation+profiles
http://scratch.drupal.org/project/drubb
http://scratch.drupal.org/project/musicians
...

so, to review, this is "Installation profiles" as the project type, and "/contributions/profiles/" as the CVS dir. best of both worlds. any final objections or is this RTBC?

dww’s picture

since i'm about to leave, and don't want this issue blocked on my travels, i just committed http://drupal.org/node/114356 to HEAD, and installed that on d.o. so, if we decide we want the term and the CVS directory not to match, someone with site admin powers just needs to create the new top-level project taxonomy term, then visit:

http://drupal.org/admin/project/cvs-settings

You'll see a textbox for "Directory for Installation profiles", and you'd just want to put profiles in there. Problem solved.

at Dries's request, i'm not going to setup the new term or CVS directory -- i leave that in the able hands of others. all i did was added the knob to cvs.module to make this possible. ;)

cheers,
-derek

webchick’s picture

Thanks a lot, Derek. Enjoy your well-deserved vacation! :)

RobRoy’s picture

Yeah, thanks Derek! Enjoy! My vote goes back to D for whenever this gets processed from the queue. ;)

mfer’s picture

Just listened to the lullabot podcast (episode 32) and it was nice to hear dries (guest interview spot) essentially give this a +1 including eventually having a "smart system" that builds a package/distribution.

Frando’s picture

So, obviously, as a next step someone from infrastructure (Dries? killes?) should set up the top-level CVS directory "profiles" and create the top-level project taxonomy term "Installation profiles" or "Distributions".

Everything else, e.g. package script improvements to package modules and themes togheter with the profiles can, even though I think it's imporant, come later, when there are some more worthy install profiles, IMO.

dww’s picture

i spoke to Dries at length about this earlier today. he's fine with moving ahead for the v1.0 functionality (just putting the .profile files into CVS, with no further packaging of a whole "distribution", etc). the only thing he wanted before i implemented the plan here is http://drupal.org/node/125750, which will hopefully be committed and installed in our contrib repo in the very near future.

dww’s picture

Status: Needs review » Reviewed & tested by the community

http://drupal.org/node/125750 is now committed and installed on cvs.d.o. ;)

we're almost there, but i'm out of time for today. this will happen tomorrow, if not late tonight.

dww’s picture

http://drupal.org/project/Installation+profiles
http://cvs.drupal.org/viewcvs/drupal/contributions/profiles/

the race is now on... who will be the first to own an Installation profile project node? ;)

dww’s picture

Status: Reviewed & tested by the community » Fixed
Anonymous’s picture

Status: Fixed » Closed (fixed)