Drupal/Component level code is intended to be reusable outside of Drupal itself via composer inclusion. Adding composer.json files to these code bases is the first step in doing that and many of those depend upon Utility, so I've begun by adding the composer.json file for utility first. This will ultimately enable us to do subtree splits against drupal core and distribute our Components into separate git repositories that others can pull from individually.

Eclipse

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

EclipseGc’s picture

I've emulated Symfony's approach to attribution here, dunno if Dries is a.) ok with this and b.) if he wants to use the email address.

Eclipse

penyaskito’s picture

+++ b/core/lib/Drupal/Component/Utility/composer.json
@@ -0,0 +1,23 @@
+  "name": "drupal/utilty",

typo :-P

EclipseGc’s picture

FileSize
782 bytes

Typo

Eclipse

EclipseGc’s picture

FileSize
553 bytes

We don't have any attribution in the base composer.json for drupal, so I just went ahead and removed it here as well. I think this probably puts this into a committable state.

Eclipse

dawehner’s picture

  1. +++ b/core/lib/Drupal/Component/Utility/composer.json
    @@ -0,0 +1,13 @@
    +  "require": {
    +    "php": ">=5.4.0"
    +  },
    

    Let's go with 5.3.10 for now.

  2. +++ b/core/lib/Drupal/Component/Utility/composer.json
    @@ -0,0 +1,13 @@
    +  "description": "Common utility classes for Drupal components.",
    

    Maybe some examples would be helpful (String/XSS)

  3. +++ b/core/lib/Drupal/Component/Utility/composer.json
    @@ -0,0 +1,13 @@
    +  "homepage": "http://www.drupal.org",
    

    Should we link to https://www.drupal.org/project/drupal instead?

+++ b/core/lib/Drupal/Component/Utility/composer.json
@@ -0,0 +1,13 @@
+  "name": "drupal/utility",

I wonder whether we should prefix the drupal core components somehow. (drupal/core-utility). Just wondering.

EclipseGc’s picture

FileSize
638 bytes

1.) Crell and I discussed this and he suggested setting it the same as D8, I didn't argue, but I see no reason to set it arbitrarily higher than what is actually needed here.

2.) OOOOOK

3.) You're not the first person to suggest that. I disagree, but am apparently in the minority, and it seems a really minor thing.

4.) Not sure what we'll do for Drupal/Core stuff... you're solution doesn't seem bad, but I question whether any of that will ever end up "composerable".

Eclipse

EclipseGc’s picture

FileSize
639 bytes

we'll make it https

Eclipse

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Let's go with that as a first step.

We should consider to create an issue somewhere to do an automatic subtree cron based splitting

The last submitted patch, 6: 2176065-6.patch, failed testing.

sun’s picture

+++ b/core/lib/Drupal/Component/Utility/composer.json
@@ -0,0 +1,13 @@
+  "autoload": {
+      "psr-0": { "Drupal\\Component\\Utility\\": "" }
+  }

Is it is very likely that we'll copy/paste this first file as a template later on, can we (1) fix the indentation and (2) turn the inner namespace hashmap onto a separate line?

In short:

  "autoload": {
    "psr-0": {
      "Drupal\\Component\\Utility\\": ""
    }
  }
dawehner’s picture

This 4 spaces clearly from the outside world which pretty much all uses 4 spaces in the composer.json files. Maybe we should discuss that somewhere.

sun’s picture

I've seen composer.json files in the wild using 2 spaces, 4 spaces, or even tabs.

I don't think there is a coding standard for composer.json files. → As long as it's valid JSON, everything works.

I don't really care which form we're going to use, but I think there is one crystal clear rule that we can all agree to:

Within the scope of a single file, the style should be consistent.

The autoload:psr-0 lines are the only lines that diverge from the rest of the file. There are multiple ways to fix this, just choose one. I'd personally prefer to stick to 2 spaces, but again, only consistency matters. :)

EclipseGc’s picture

FileSize
649 bytes

You are completely right, my bad.

Eclipse

sun’s picture

Thanks! :-)

Now, personally, I'd like to perform the following change for maximum accuracy + architectural sanity, but I'm not sure whether we're able to do it right now, because AFAIK there is at least one offender (Settings):

-  "description": "Utility classes for Drupal components including string, xss, array, image and other commonly needed manipulations.",
+  "description": "Static utility classes for Drupal components including string, xss, array, image and other commonly needed manipulations.",

In other words: Any class that is not a static utility function class (mainly wrapping PHP core code) has absolutely no place in \Drupal\Component\Utility. It concerns me that this is not a hard requirement for \Utility.

That said, I'd also drop the "Drupal components including" part. → By exposing them to the public, they are no longer for "Drupal components" only. :P

-  "description": "Utility classes for Drupal components including string, xss, array, image and other commonly needed manipulations.",
+  "description": "Static utility classes for string, xss, array, image, and other commonly needed manipulations.",
EclipseGc’s picture

what about:

"description": "Mostly static utility classes for string, xss, array, image, and other commonly needed manipulations.",

??? I know, it's totally suboptimal, but at least it's honest.

Let me know.

Eclipse

sun’s picture

"Mostly static" is an excellent idea and compromise! :-)

EclipseGc’s picture

FileSize
636 bytes

Ok then.

Eclipse

Damien Tournoud’s picture

The license property doesn't seem to match the documented ones. From the doc, we should be using GPL-2.0+.

EclipseGc’s picture

FileSize
639 bytes

Sorry, didn't realize there was a page documenting that standard. Thanks!

Eclipse

Tor Arne Thune’s picture

https://www.drupal.org/ redirects to https://drupal.org/ so wouldn't it be more correct to use: https://drupal.org/project/drupal ?

EclipseGc’s picture

FileSize
635 bytes

Seems kosher.

Eclipse

Damien Tournoud’s picture

Looks like a good start.

webchick’s picture

Assigned: EclipseGc » Dries
Issue tags: +Needs issue summary update

I have no idea what this is for, let's get an updated issue summary.

When I asked Eclipse what it was for, he said it was to allow Component to be split off and that sounds like a strategic question, so also assigning to Dries. This might not actually need to happen, but I can't tell because there's no issue summary. :)

EclipseGc’s picture

Issue summary: View changes
Crell’s picture

Parent issue: » #1826054: [Meta] Expose Drupal Components outside of Drupal

Adding parent issue for context.

dawehner’s picture

@webchick
So yeah it is not about splitting up the code itself, it is about supporting people which want to reuse the component in NON-drupal variants.
Theoretically this is already possible, though it is kind of a mess without the composer.json file.

EclipseGc’s picture

I updated the summary but failed to remove the tag.

Eclipse

EclipseGc’s picture

tstoeckler’s picture

+++ b/core/lib/Drupal/Component/Utility/composer.json
@@ -0,0 +1,15 @@
+  "description": "Mostly static utility classes for string, xss, array, image, and other commonly needed manipulations.",

"xss" should be "XSS", I think.

sun’s picture

I'm not sure why this needs approval from Dries — for now, the intention is just to perform periodical git-subtree splits (exports) from git.drupal.org/project/drupal into standalone repos per component. The "master"/originating code stays in core.

The composer.json only needs to be added to core, because the subtree-split should be a 1:1 copy of the originating code. A composer.json file is required to use a standalone component with Composer.

In essence, we want to do the exact same thing as Symfony: All Symfony components are maintained in a single project repository, and each of them is split/exported into a standalone repository. This allows other projects (like Drupal) to cherry-pick the components they want to use.

EclipseGc’s picture

Thank you sun for explaining what I appear to be incapable of communicating.

sun++

Eclipse

EclipseGc’s picture

@tstoeckler

I'd prefer to not do that since they're all currently lower case, consistency and all, and I don't have to decide if various elements of this need additional capitalization.

Eclipse

Dries’s picture

This looks like a good idea to me (but a low priority).

I'm fine with having read-only clones outside of core, but for now I want these components to be maintained in Drupal core itself.

effulgentsia’s picture

Assigned: Dries » Unassigned

Unassigning from Dries since he answered.

EclipseGc’s picture

Yeah, I think we have the same goals in that regard, all this does is make it possible for us to begin working toward that goal. Thanks for responding! I think we're still RTBC.

Eclipse

alexpott’s picture

Title: Introduce a composer.json for Drupal\Component\Utility » Change record: Introduce a composer.json for Drupal\Component\Utility
Status: Reviewed & tested by the community » Active
Issue tags: +Missing change record, +Needs change record

Committed a50ebdf and pushed to 8.x. Thanks!

I validated the the composer json by running composer validate core/lib/Drupal/Component/Utility/composer.json

I think we should have a change record to detail the purpose of this.

EclipseGc’s picture

Added a change record.

Eclipse

EclipseGc’s picture

Status: Active » Fixed
EclipseGc’s picture

Title: Change record: Introduce a composer.json for Drupal\Component\Utility » Introduce a composer.json for Drupal\Component\Utility

Status: Fixed » Closed (fixed)

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

Xano’s picture

davidwbarratt’s picture

Mile23’s picture