Add UUID generation functionality to CTools

Why wouldn't the uuid.module be used instead?

Also, 7216356 is not a node ID. Where is this RTBC? Patch authors shouldn't RTBC their own patches.

My question about uuid.module was not about the entity functionality, but uuid's uuid.inc.
It has a wrapper function uuid_generate(), which detemines if PECL or COM can be used, and otherwise falls back to PHP.

It also borrowed from the same code, except it was found to be buggy. See #1596350: _uuid_generate_php() does not create valid UUID v4 UUIDs., if we decide to duplicate this code, we should duplicate the right code.

+++ b/ctools.module
@@ -368,6 +368,71 @@ function ctools_set_no_blocks($blocks = FALSE) {
+ * @copyright   Copyright (c) CFD Labs, 2006. This function may be used freely
+ *              for any purpose ; it is distributed without any form of
+ *              warranty whatsoever.
+ * @author      David Holmes <dholmes@cfdsoftware.net>

We don't need to include this.

Looks pretty good to me, but we should use ctools_include() for our files.

All the different generators do make me slightly uneasy. In theory they're all interchangeable, but I'm somewhat inclined to suggest checking something like variable_get('ctools_uuid_generator') first and foremost, so that people can hard-code the one they want to use in their settings file if necessary.

For the PECL generator, do we want UUID_TYPE_RANDOM rather than UUID_TYPE_DEFAULT, for consistency with _uuid_generate_php() ? (I'm assuming the RANDOM type is UUID v4)

I also see that you're checking for the incompatible php5-uuid package with the test for uuid_make() (https://answers.launchpad.net/ubuntu/+source/ossp-uuid/+question/87216), but we should add a comment to explain that.

(Edit: Or are my compatibility & version concerns unfounded? I suppose if all 'versions' of UUID are validated by the same function, perhaps it doesn't actually matter which version is being generated? I haven't looked into this at all. Comments, anyone? The hard-coded version bits would certainly negate the possibility of collisions between UUIDs of different versions, so perhaps there isn't a problem...)

(Edit 2: deleted comment about static caching, as that was already in the patch; apparently I'm blind.)

Cross-referencing with #2179475: Clean up _uuid_generate_php().

(I wanted to clean it up for ctools, but it seemed best to post in the uuid queue).

Since CTools is everywhere thanks to Views depending on it, can't we have UUID depend on CTools and leave the UUID only in CTools? Duplicating efforts suck.

#13, you'd have to open an issue against the UUID module for that...

The committed patch breaks Panopoly install:

PHP Fatal error:  Cannot redeclare _uuid_generate_com() (previously declared in /home/travis/build/lsolesen/drupal/profiles/panopoly/modules/contrib/ctools/includes/uuid.inc:19) in /home/travis/build/lsolesen/drupal/profiles/panopoly/modules/contrib/uuid/uuid.inc on line 158

What I think is happening, is that CTools is installed (and includes uuid.inc because module_exists('uuid') == FALSE) and then UUID is installed, which redeclares _uuid_generate_com().

I'm not sure where the fix should be yet, if it should be in Panopoly or Ctools. Once I do, I'll make a new issue in the appropriate queue.

FYI, we ended up addressing this in Panopoly by reordering the dependencies in the .info file:

#2186405: Revert: Installing 'ctools' (1.4) before 'uuid' during Panopoly install causes fatal error

But this incompatibility between 'ctools' and 'uuid' inside of install profiles should probably be documented somewhere!

It should be fixed, methinks.

I feel there's no good reason for Ctools' copies of those private functions to still use the UUID name-spacing. That's not good practice.

Let's change them, and thus guarantee there won't be conflicts.

FYI, @japerry did just that in this commit: http://drupalcode.org/project/ctools.git/commitdiff/f16fce929bc0dec36797...

Problem solved!