We aren't actually using the 'uuid' module for anything in Panopoly and there is fun install race condition when trying to install both 'uuid' and 'ctools' in an installation profile: #2186405: Revert: Installing 'ctools' (1.4) before 'uuid' during Panopoly install causes fatal error

There was a fix in Ctools (huzzah!) to resolve the conflict. :-) But, I still think it's worth discussing it's removal from panopoly.info. I'm not sure what it's use case is in the context of Panopoly. We're not going to use features_uuid -- we'd use migrate for that! Services/Deploy/etc are outside the scope of Panopoly itself and more for a distribution built on it...

What do you think?

Comments

dsnopek’s picture

Issue summary: View changes
skwashd’s picture

I am one of the co-maintainers of UUID. I disagree with the UUID implementation in #2155825. IMO CTools and/or panels should have just added UUID as a dependency. The current implementation reminds me of the NIH attitude that Drupal 8 is trying to overcome. Including UUID as a dependency makes it clear to others that Panopoly believes that developers should be building on top of existing modules not copying and pasting code without attribution.</rant>

dsnopek’s picture

Hi @skwashd! Thanks for joining the discussion. :-)

Please don't take this discussion as a negative statement against the quality or usefulness of the UUID module! The UUID module is great and has several important use-cases. I've personally used it on several projects and will certainly use it again.

This is one of several discussions we've been having for months about removing things from Panopoly:

#2063541: Remove Open Sans?
#2105503: Implement demo content via Migrate instead of defaultcontent
#2139481: [meta] Should we remove functionality from Panopoly?
#2166865: Removing non-required modules from .info / .make files
#2186421: Remove 'defaultcontent' dependency from panopoly.info

And we'll probably continue to discuss them for several more months before we've made decisions and taken action on all of them!

This is a very complex discussion with many considerations because:

  1. Panopoly isn't just one thing - it's several things: (a) an installation profile, (b) a base distribution to build other distributions on and (c) a set of modules that can be used individually outside of any distributions.
  2. There are many ways to "remove" things: (a) from the installation profile dependencies (panopoly.info), (b) from one of the *.make files or (c) from one of the module dependencys (panopoly_*.info).
  3. There are some really serious technical problems with removing things that need to be resolved, see the discussion in #2166865: Removing non-required modules from .info / .make files

So, for example, if we removed the 'uuid' module from panopoly.info but NOT the .make file (which is what I'm suggesting in this issue), it would only affect new users to install the Panopoly installation profile but NOT existing users, any of the child distributions built on Panopoly, or users of the panopoly_* modules.

The reason for these discussions is multiple fold (and probably should be documented somewhere):

  1. The more things we include can make it more difficult for child distributions to customize, because they have to override our stuff (ie. #2139481: [meta] Should we remove functionality from Panopoly?, #2063541: Remove Open Sans?).
  2. Maintaining a distribution is hard (and a base distribution even harder)! This is largely because the complexity and work increases as we add more modules. Most of the modules are included because we actually use them in the panopoly_* modules, but some we don't, like 'uuid'. That's just included because we like it. :-) However, now we've started discussing removing everything we don't use (although, only actually removed one thing so far: the 'defaultcontent' module). Users or child distributions who need any of these modules for their use-cases can still install them, but then the maintenance is their problem, not ours.
  3. Fewer random things sitting around if the user or child distribution decides they don't need them. Once things are in any of our *.make files, our users are stuck with the modules on disk even if they never intend to install them.

Anyway, the point is that this discussion really isn't just because of the momentary conflict (it only lasted one day!) between CTools and UUID and I'm sorry for giving that impression. Yes, I created the issue while trying to resolve that conflict -- because I really wanted to get our community testing the new CTools/Panels code, see: https://groups.drupal.org/node/403098 -- but removing unused modules like 'uuid' was something that we were already talking about.

I have no personal opinion about which module should implement the API code for generating UUIDs. But I really do hope that the CTools and UUID projects can come to some amicable resolution because I love both modules and I think that the overall health of the Drupal community is best served by great projects communicating and collaborating. :-)

Anyway, thaks again for joining this discussion! See you around on Drupal.org! If you'd like, maybe we can chat on IRC or do a call over Skype or Google Hangouts? Take care!

barraponto’s picture

@skwashd i don't like the implementation used in ctools either: we should avoid duplicating efforts. However, the UUID module bundles the UUID-generation logic with a module that uses it for Entity UUIDs. Since Panopoly (and Views and Panels) only needs the logic, it made sense to bundle it into CTools.

Now there's the option of letting the CTools users maintain that logic (and every Views user is a CTools user, we're talking about a big user base), or making CTools depend on UUID (which depends on Entity API) and having a strong contributed API atop core's API.

I'm all for either approach. This should be discussed on CTools or UUID queues, though.

caschbre’s picture

Just to reiteration a bit of dsnopek, we're not really debating the ctools vs uuid modules. We love them both. We're simply minimizing modules we include in .make files or require in .info files to reduce the overhead on testing, maintenance, etc.