Grayside.Org - features-servers

Drush with Bash Aliases

Grayside — Thu, 10 Jun 2010 06:18:40 +0000

I’ve been looking for some decent ways of managing the use of modules hosted in random Features Servers. Particularly, how do I use Drush as seamlessly with a Features Server as it works with Drupal.Org?

It turns out that Drush has a lot of special options buried in the pm-download (dl) command, the very Drush maneuver most helpful for my goal. Naturally, these options can be included in a Bash Alias for Drush.

alias dds='drush --source=http://code.developmentseed.org/fserver dl'

This alias specifically searches DevSeed’s features server for projects. Slide it into your .bashrc file. Now a quick $> dds fserver works like a charm.

I still think project repositories like Ubuntu’s package repos (or really, Arch repositories like Core, Extra, and Aur) have a lesson for us. But that can wait on the smoothing out of functionality like –destination, which allows you to say where a project will be saved, but not with the same grace as Drupal.Org projects and the modules/contrib/ directory.

Terms:

drush

features-servers

Integrating the Features Server into OpenAtrium

Grayside — Thu, 03 Jun 2010 16:32:53 +0000

Working on integrating the Features Server feature into OpenAtrium. My intention is to set it up as another Casetracker Project type.

OpenAtrium provides a solid case tracker and documentation system, and is a natural fit for the infrastructure of a Drupal.Org-style project ecosphere. Integrating them will allow me to post Features I’ve created to a place where I might actually have a means to get feedback on my work, let alone provide support.

Project Status of OA Features Server feature

Features Project as a Casetracker Project ✓
Features Project automatically a Notebook ✓
Converting Projects View to a Site/Group feature. [in progress]
Trivial Modification of Features Server code to play nice with OpenAtrium and Atrium Casetracker .✓ [will ship with patch]

Conundrums

Features Server feature uses Context 2.0, OA uses Context 3.0
hook_views_default_views_alter() has limited to no best practices or examples I’ve been able to find, given it’s currently documented intention as a site-specific hook. Somehow I don’t think it’s role will remain in site-customization in the world of Features.

Terms:

drupal

openatrium

features-servers

Feature Server Aggregator

Grayside — Fri, 07 May 2010 06:44:56 +0000

This was supposed to be my next blog post, when I finished mulling it over. Then I saw @open_atrium twitter the exact words.

I’ve been wondering what good a Feature Server is if every individual server had to handle it’s own marketing if anyone was going to learn about it. Google is a bit hard to use with keywords like “Drupal Feature”.

Terms:

features-servers

Feature Server: Not That Hard

Grayside — Fri, 07 May 2010 06:27:40 +0000

It turns out that running your own Feature Server isn’t that complicated. Get a Drupal site. Install the fserver feature. It’s most exotic requirements are Filefield and Context, and context is just their to facilitate easy block placement of release information.

All the feature really does is provide a fancy XML Views style plugin, a couple content types with their CCK fields to specify things like version information, and some special file-handling magic to push files and tarballs around.

It slid into this blog site very easily, and now I have a very clean way of upload and sharing Drupal code and functionality snippets. But should I leave the fserver as part of my blog? The last thing I need is to release a couple popular features into the wild and have to worry about the Update Status module pinging my words to death.

Terms:

features

features-servers

Drush and Features Servers

Grayside — Sat, 01 May 2010 07:14:15 +0000

Feature Servers have great potential to help structure the use of code sourced outside the formal ecosphere around Drupal.Org this has it’s pro’s and con’s, but I already see their usefulness in providing a little more structure to issue-queue code exchanges and organization-internal modules. So let’s bring Drush into this and boost the ease of use of that usefulness another step up.

For those who need more catching up:
Features are a special kind of Drupal module built on the features project. They allow you to easily export configuration from your site into a module usable on any site. Modules downloaded from a Features Server are the next best thing to one posted to Drupal.org. DrupalConSF has a great video.

Current State

The rise of Feature Servers, and perhaps other types of code release repositories would benefit from a little Drush magic. The little-documented option of –source is a starting place:

drush --source=http://code.developmentseed.org/fserver/ dl fserver

This code will grab the latest, most recommended release of the Feature Server code from DevSeed’s feature server.

Future Directions

I’ve started an issue in the Drush queue to talk about some kind of repository scheme to help manage the download and file placement of code from individually preferred repositories.

Terms: