Hi I maintain a module which has had drush integration patched in ( http://drupal.org/project/node_export )

This is how the original commands were set up:

To export (nodes 45 46 and 47 into a file called 'filename'):
'drush node_export 45 46 47 --file=filename'
To import:
'drush node_export import < filename'

Now because of changes in drush, "drush node_export import" has to become "drush node_export-import" which looks a bit strange to me, and might be tough to remember.

I actually thought 'node_export' was the command and 'import' was a flag/arg/param, but apparently that's not how it was set up. It is actually part of the command.

So I was wondering what the best and most consistent way to set up these commands is? Are there any modules that provide drush integration, that have more than one function to supply to drush, that I could take a look at?

Ideally I would like to see something like

drush node_export -import < filename
and/or
drush node_export -i < filename
and

drush node_export -export 45 46 47 --file=filename
and/or
drush node_export -e 45 46 47 --file=filename

but if you don't supply the first param (-import/-i, or -export/-e) it will assume -export

Also there is a desired secondary functionality to export where you don't supply a list of nids, but rather a list of node_types, so the full function would ideally be something like so:

drush node_export -export -types page story

If anyone can provide some useful guidelines about formatting commands, or examples, I would greatly appreciate it.

Original issue: #766930: Drush 3 compatibility

Comments

greg.1.anderson’s picture

greg.1.anderson commented

First off, I would recommend against using 'node_export' in the command. 'node-export' would be better. 'node-export-import' is a bit wordy. 'node-import' would be better.

I would recommend against using an option to select the command. Usually, arguments are used to select a target, the command is the verb that operates on the target, and options change aspects of the operation (e.g. formatting options on output, auxiliary information such as cache folders, etc.)

So, in other words:

drush node-export 45 46 47 --file=filename
drush node-import < filename
danielb’s picture

danielb commented

Thanks for the response.

The problem for me there is that there is another module called "node import" which has a different purpose (mapping data into nodes from CSV files), and I don't want to step on any toes in case they want drush integration too. ( http://drupal.org/project/node_import ).

I would also imagine that for staying consistent with other drupal standards, you would prefix everything you do (filenames, functions, key names, etc..) with the name of the module.

The other issue is that the module's short name is node_export with the underscore, so people might be tempted to type that. I'd consider making several variations of the commands available, like node_export-import and node-export-import just in case someone mistypes it??

greg.1.anderson’s picture

greg.1.anderson commented

The usual standard is that function names (and module names) use underscores, but command names use hyphens. It is typical that a function name or module name that uses underscores should map them all to hyphens when making equivalent drush commands. Previously, the underscores were mapped to spaces, when spaces were allowed in drush command names.

Command names that may conflict with other modules' choices are more difficult, esp. since in the case you mention above, it is entirely conceivable that someone might want to use both the node_export and the node_import module. In that case, I think that the best thing would be if your node_export modules could unambiguously identify its own exported files. Then, the drush node-import command could import via node_export if the import data came from node_export, or pass along the data to the node_import module if the data is a csv file.

Of course, you probably don't want to handle the drush integration for other people's modules, so the ideal solution is perhaps not practical. (The other downside is what if someone wanted to use node_import without node_export; that would be a pickle.)

Do as you think best.

danielb’s picture

danielb commented

Cheers, you've cleared things up for me.

greg.1.anderson’s picture

greg.1.anderson commented
Status: Active » Fixed

Glad to hear it. Best of luck.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.