Decide on package name

[webflo]

@winmillwill: thanks for moving your repo to this organization.

I think we have to decide on a new package name? I think it is best practice to the name on github and packagist? Or at least we have to update the git url https://packagist.org/packages/drupal/parse-composer

[winmillwill]

tl;dr -- I'm fine with any name matching this regex:

/^drupal(-composer)*\/parse(r)*(-(d\.o|drupal\.org))*$/

The confusing thing for me is that it's not clear what the packagist namespace (everything in front of the /) is supposed to correspond to. If it's supposed to be analogous to the github namespace, then that makes this package drupal-composer/drupal-parse-composer, and the most terse option with no repetition would be drupal-composer/parse which is sort of a weird ordering of words, but still better.

The next thing to figure out is whether and how to advertise what exactly we're parsing to make composer metadata. Right now, the code parses .make, .info, and .info.yml files and composer.json (kind of) and it parses release info, though that may not be essential anymore. I guess my point is that we might benefit from putting together a list of all the types of data we need to interpret to make a working composer repository that represents all of drupal.org, and then deciding on whether those data sources each need their own library. To just name this thing now, I'm fine with vendor/parse or vendor/parser.

An issue that we're going to run into is what the target namespaces should be for all of these:

• code developed for Drupal proper (Drupal core and tooling for the CI, etc)
• code developed and published on drupal.org that is not composer-aware
• code developed for use on the web application drupal.org
• code developed after composer is truly adopted for Drupal (yes, being optimistic)

When I had to put composer.json files in modules so I could use them, I just called them drupal/whatever because the fact is that the way that drupal code works, your name has to be unique with respect to any other info file that could possibly exist. So, whether you have merlinofchaos/views or drupal/views the fact is that the class namespaces are going to start with Drupal\Views and the module name is going to be views, so it's not possible to avoid collision by choosing a different vendor name for your package anyway. Moreover, if you fork, then you certainly don't change the vendor part of the name, because the ideal outcome is that your changes are accepted upstream, so you can stop pointing a consuming project at your fork.

Thoughts?

[derhasi]

On my packages I can edit the Repository URL via packagist. Maybe that would be enough to make the change without the need of a rename?

Once [policy, no patch] Decide on Composer Package Names (drupal.org) is resolved, changing the name might be necessary. But I do not see that an issue for now.

Making clear what info is parsed could be something we can provide on the frontpage of drupal-packagist. But that would be another issue 😉