What is the best approach to packaging combinations of features? David, Andre said that you were doing a review of the different options? Could you comment on how you are progressing?
I know of
Package Builder
Patterns
Features
but being pretty new to this I'm sure there are other options. I've tried Features and Patterns and both seemed useful. I would like to establish an agreed method for developing a feature, once the spec is defined, and packaging it such that it can be rolled out into public dev sites. Partly this touches on workflow, between Chris, John and myself we've discussed documenting the steps to create a feature and then repeating those steps on a dev or staging site. But packaging as a feature or defining a pattern that can just be executed is much more repeatable.
Something else I would like to understand is how best can a feature be edited as requirements change? If a feature is defined as a Pattern, it could be edited as a text file and run again on a site. With Package builder I guess the package would need re-creating and re-installing to other sites? What are the tradeoffs here?
I'd like to push on with features for my group's site soon but in a way that will fit in with this work where possible.
So please pitch in with suggestions :-)
Comments
As a related question, what
As a related question, what exactly is Transition Drupal going to be, deployment-wise? Is it what the Drupal folks refer to as an "installation profile"? And does that allow you to prepopulate things like taxonomies?
David might not know this
David might not know this question is here. He is looking into how we're going to deploy. He has begun looking into Package Builder vs. Features. His first writeup is here:
http://davidherron.com/content/quick-look-package-builder-module-drupal-...
Yes, it's going to be an installation profile aka a "distribution."
Andre Angelantoni
Founder, PostPeakLiving.com
So as I understand it, the
So as I understand it, the point of Features/Package Builder is to take data that would normally be confined to the database and put it in a portable format that can be checked into the source tree, right? Does that include content? That is, would it be possible to include, say, a "book" about Transition in the source tree? Or, to put it another way, is there anything that can't be included in the source tree? Say, user comments?
On a related note, would it be possible to put some sort of test content in the source tree now so that the developers can test that their local install is actually being synced up?
Yes
I'm not sure how Features/Package Builder works and I've asked David to chime in here but I think all the above is possible. Having some basic pages even with some initial content I think was always part of my vision and David's, too. Each TT group will likely want pages on similar topics with links to existing resources that they can then change at will.
As for your second question, I can put something in the repo if you'd like but with the invitation I sent you I think you should be able to upload some code, too. Try committing a local D7 install then downloading it to another directory and see how it goes.
Andre Angelantoni
Founder, PostPeakLiving.com
Having some success with Patterns
I tried Features and it does package as described, but I've not played a lot with it.
I've gone initially down the road of using Patterns and have had some reasonable success with that. See http://trac6.assembla.com/transition-initiatives-web/browser/transition_... for the files I've created so far. They are part of a v6-based repository I've setup to create something in the short term, but I am really keen to ensure that this is done collaboratively and hence we all keep in sync if at all possible, and explore ways to share work between v6 and v7 versions.
Ok, I did the following: %
Ok, I did the following:
% git clone git@aangel.unfuddle.com:aangel/td-d7-standard.git
% cd td-d7-standard
% cp -r cygdrive/c/xampp/htdocs/drupal .
% git add .
% git commit
% git push origin master
Now when I (and presumably anyone else) does a clone from the remote server it pulls down the entire contents of my drupal directory (which is from a fresh D7 install). So are you sure that we want to include all of those files in git, or will we only be making changes under certain sub-directories (eg modules)?
Just playing
Hi, Wes. I recommended uploading some code just so that you could test your local dev environment and play with the tools a bit. The core developers still need to decide how we are going to set up the repo...it almost certainly won't look like how you have it now because we need to plan the branch strategy for both core files and modules.
I wasn't going to arrange that conversation until the first beta of D7 was released but if you'd like to get that going now we should probably get you, me and David on a call so that we can go through the options more quickly. We should also think of where the graphics people might want to store their design (i.e. photoshop) files (distinct from the theming files Drupal uses).
I've been using www.doodle.com to set up meetings and it's worked well. I'm around all next week but Tuesday night is bad for me (upgrading a live D5 site to D6).
Andre Angelantoni
Founder, PostPeakLiving.com
I agree there's no point in
I agree there's no point in working out a branching strategy until we have some actual sample changes to propagate. In the meantime I can figure out which files do what just by creating some branches off the root directory.
Team members
Regarding the development team, could a page be written up with the members in different areas (dev, IA, etc)? As development is the area I could probably contribute to most I'd certainly at least like to keep in sync with this. I'm a bit unclear Andre quite how you see the structure of this project, who contributes and so on.
See
http://transitiondrupal.org/reqs-1.0
Then click Project Team
Andre Angelantoni
Founder, PostPeakLiving.com
difficult
My understanding of packaging is that it's still really difficult, every feature and setting needs to be managed differently. For Community Forge , I opted against the installation profile, and created a single module with large installation script which sets variables, and writes directly to the database, and saves vocabularies, menu links, and terms using the api. I've learned a lot about localisation through this - keeping the locale tables up to date is a constant drag. I don't think features or patterns make any of this any easier, unfortunately. Patterns require a lot of setting up in code and features only seem to incorporate a few elements of Drupal so far - not variables, not menu items, not nodes.
Setting up a site requires running the default installation profile in the required language, and then enabling the module. First the module installs all its dependencies, then imports the po file (an export of all the strings on the site), then goes through configuring all those modules and adding its own pages, vocabularies, menus, menu links roles, permissions etc.
If I had to do it again I would probably create an empty site and just copy paste it. then I would update the existing sites using hook_update. I still wouldn't bother with any of the official ways. I think the proper way to do this is for Drupal to provide import and export hooks so each module can save its settings in code. Ctools seems to be trying to help with this but i haven't looked in detail.