Please leave your comments for the Autoload path depth insanity blog post on this gist.
Any type of feedback is welcome. Including alternate suggestions, corrections, insults, etc. Thanks!
P.S.: I apologize for the crappy format. I will try go get a better way to post comments soon, promise!
I have to admit I don't fully understand the problem. You say you don't care about the directory structure in vendor because "you don't interact with them often". So why is it a problem in your project then? The class_prefix you propose can already be emulated by composer if I'm not completely wrong. Look for example at this library: https://github.com/lanthaler/JsonLD. There are no unnecessary directories at all since composer has been told that the root dir represents ML\JsonLD:
...
"autoload": {
"psr-0": { "ML\\JsonLD": "" }
},
...
@lanthaler I think that the idea here is that @igorw would still like the flexibility to have the source be under src/ and not force everything to be in the root of the repository.
@lanthaler you are mistaken, and this is in fact covered in the FAQ in the blog post. The JsonLD library has the source code at the root of the project and uses target-dir. The reason I do not want that is because I prefer a top-level separation between source code, tests and other resources like documentation. For this reason, I want a src directory at the top level.
My proposal would be able to replace target-dir. But target-dir is not able to support my use case.
FWIW, I agree. It would be a small improvement.
On the other hand, I think PSR-0 has bigger issues, namely I'd like to be able to separate classes on the file system for logical grouping while browsing, but still have them in the same namespace because they belong together and that would reduce use-hell.
For example, all the Exception subnamespaces make no sense IMO. Why should I use Vendor\MyLib\Exception\FooBarException; from Vendor\MyLib\Logic? Simply throwing FooBarException would be easier, but if I want to stow away my exception classes under a subdir to avoid cruft in the main one, I have to use a different namespace.
Obviously this would be a broader divergeance from PSR-0, and I am not sure if there is a way to define rules to allow this to work as I want without allowing a mess to emerge. Obviously I could already use classmap right now to do this, but as @igorw pointed out, that has drawbacks too. Anyway just throwing this out here, in case someone else has an idea.
A number of people have raised a similar issue in Drupal as we've been pulling in more and more 3rd party libraries. I like this idea overall. Please do submit it to FIG for discussion. :-)
I am so glad to see this raised @igorw Earlier today, I made a suggestion in the PSR forum regarding this issue.
My suggestion is simple. No programming changes. No standards changes. Just a change in the practice of how these package repositories are created.
If we use a folder structure for the packages (components), like this:
http://s7.postimage.org/7ar0rbvmz/Screen_shot_2013_02_10_at_9_04_50_AM.png
And, use class maps for unit testing, Composer and Packagist install the package neatly under the Vendor folder and there is only one occurrence (not two) of the Vendor/Package layer.
I posted my question https://groups.google.com/forum/#!topic/php-fig/-BPdegzme_Y - although I should have been more clear -- the discussion seems to be heading into areas other than this double layers of the Vendor/Package issue.
Would using the directory structure pictured above for packages be a reasonable solution?
@Seldaek - the issues you are raising are important, in fact, it leads into best practices for overrides. As a separate discussion, It would be good to see your topic further discussed, as well.
Well, I don't have much to add in this discussion, just would like to say that I honestly like the idea and Im sure this would have helped me when I first started to work with psr-0 autoload. I remember very well how I hated the folder verbosity when I realised that I NEEDED to use this crazy structure, even for something very simple. [+1]
I agree completely on this proposal. I hate pointless directories like
src/CompanyName/ProjectName, especially when there is only oneCompanyNameinsidesrcand only oneProjectNameinCompanyName. And this crap inside every module / bundle! We should stop this madness.