Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
2.0: Let us use multiple slashes in the package name. #7975
Drop the requirement that package names follow the form vendor/package-name. Let us use as many slashes as we want. It's like this now in version 1, and it's better that way.
Consider these examples:
This is very clean. Libraries (mechanisms with no awareness of business logic) are separated from Services (business logic serving endpoints), and related Service types are in their own namespaces. The namespace looks like the package name, which looks like the repo URL. The only difference is that StudlyCaps turns into snake_case. See how nice that is?
We can already do this in Composer 1, and it's extremely good! Don't impose this limitation on Composer 2.
N.b.: I understand that Packagist will not support this, which is fine with me. I also understand that some third-party tools may not support this, which is also fine with me. I don't see the point in hobbling Composer's behavior over external software. I am not uploading to Packagist, and my toolchain works just fine with multiple slashes.
There is no requirement that the package name matches the gitlab path really.. What's wrong with vname-library/matrix-math or vname/lib-matrix-math or similar?
It'd mean you have standard package names that will work everywhere no matter if you decide to change your toolchain in the future.
The thing is, this change breaks something that already works fine the way it is, and it makes lots of busy work for every developer who is using more than one slash.
It doesn't work with Packagist, but that's fine. Composer is not Packagist, and Packagist is not the only valid use case for Composer. If Packagist has some limiting assumption that means you can only have one slash, I am fine to change the package name if and only if I am going to upload to Packagist, which I am not.
If it doesn't work with some other 3rd-party tool, the reasoning is the same.
It's fair to point out that Composer is not a quaint garage project. If you break something, it can make problems for thousands of people all over the world. Of course, there is a way that both of us can be perfectly content, and nothing needs to be broken: Turn the error into a warning, do not stop execution; and give us a flag in composer.json to mute the warning, which is off by default. See? Everyone gets exactly what they want. Unwary developers get the warning, and they have to manually disable it if they don't want to see it any more.
If that isn't enough to change your mind, consider the scenario of going forward with this change:
Now, consider the scenario of leaving this alone, and someone runs into a problem trying to upload to Packagist:
Which of these two scenarios causes more harm, and wastes hundreds of thousands of dollars of dev hours? Which of these two scenarios impacts only those who are using Packagist or whichever 3rd-party tool?
You talk like this problem applies to thousands of developers, yet so far nothing seems to indicate that. We will keep the warning for a while longer to see how things evolve.
My assumption is most people follow the foo/bar naming convention because that's what they've seen used in the wild as it's enforced on packagist.org.
With respect, neither of us knows whether it's thousands. It seems likely to me that it is; we use multiple slashes at my company, and we're not from Mars or anything. Most professional developers are not at liberty to upload their work to Packagist, so unless we have the energy to contribute to open source after 40-60 hours in the office, we wouldn't find out that way.
You have two choices. One of these choices will definitely cause problems for a number of people that neither of us can predict ahead of time. Maybe it's 50. Maybe it's 5,000. (PHP runs most dynamic websites, and Packagist is supplying half a billion installs per month, so even 5,000 is a vanishingly tiny fraction.)
The other choice merely warns people who use multiple slashes, and doesn't break anything. No one has to take time away from other projects to fix anything, and no one is going to file a support request on this tracker because their build process broke.
referenced this issue
Feb 18, 2019
People getting creative is a constant source of issues and discussion. The documentation has always been rather clear on this issue however: https://getcomposer.org/doc/01-basic-usage.md#package-names