PSR-0, gitHub, Composer and Packagist

[Amy Stephen]

I am interested in hearing how others handle this and also if additional recommendations might be helpful on PSR-0.

There is a side effect of combining various technologies and following best practices that does seem quite polished.

The distribution ends up with "double sets of folder layers" when you adhere to:

• PSR-0 standard for the namespacing:
• Vendor/Package/More/Stuff
  
• A "standard" folder structure for your package repository that supports PSR-0
  
• src/Vendor/Package/now-here-is-the-actual-package-code
• Unit testing within your package repository using standard namespaces
• therefore, exisitng folders like test, build, doc, etc, and files on the root for travis, etc.
  
•  Composer and Packager - installs an entire repo, (to the best of my knowledge) no "install from a subfolder" option
• Meaning you can't install from the bolded part src/Vendor/Package/now-here-is-the-actual-package-code

Impact on folders installing Symfony HTTP Foundation:
http://s4.postimage.org/7h9hcyv99/Screen_shot_2013_02_10_at_8_57_40_AM.png

As is demonstrated in the image, the "symfony/http-foundation' values appear twice. I understand there is no impact to namespacing, but is also no need for those extra folder layers, it just creates clutter, add clicks for a dev to look at code.

What I tried, wondering if it seems like a legitimate approach:
http://s7.postimage.org/7ar0rbvmz/Screen_shot_2013_02_10_at_9_04_50_AM.png

I removed the src/Vendor/Package levels in the folder for my github package . And, I created a .dev folder (that's not really hidden, not sure about that), that holds all the tests, doc, build, bootstrap and phpunit.xml.

The way that I kept the testing functioning in the package repository was to use a class map for the namespaces. This is, of course, not in compliance with PSR-0 -- so I used my own spl_autoload which simply looks into that classmap array.

Then, when I install through Composer/Packagist, those extra levels are eliminated but the folders needed for the standard remain.

I felt this was a reasonable approach that is still PSR-0 compliant as a package is never intended to be used standalone, while the installation itself supports the standard completely.

What are others doing? Is anyone as nitpicky as I am on these things? Assuming you agree it's bothersome, should there be a recommendation on a standard approach that others might benefit from?

Or, is the way forward to adapt Composer/Packager to add an install from subfolder option? (And do you feel tests MUST be included or would it be nice to have an option to not include this dev material in a distro.)

If there is a better place for this discussion, let me know and I will post there. Thanks!

[Sebastian Krebs]

Hi,

Well, this discussion appears on the composer mailinglist from time to time. You can repeat your question there. But in short: Why do you invest your precious time to to change a working system, just because "its ugly"? Usually you don't need to look into the "vendor/"-folder, that is something composer takes care for you, so at the end it doesn't really care, whether it is ugly, or not ;)

Regards,

Sebastian

2013/2/10 Amy Stephen <amyst...@gmail.com>

I don't see a reason to _exclude_ it....

 

If there is a better place for this discussion, let me know and I will post there. Thanks!

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/ZVR_4gVMoIkJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
github.com/KingCrunch

[James Gilliland]

That does seem like a sort of cop out. We never need to debug other peoples code right? Or dig in and see how an interface is defined or copy some boiler plate code? Or just figure out the logic happening in some class so we understand how to properly use it. This is open source after all. Basically, I think the reason it keeps coming up because we /do/ have to interact with it.

[Amy Stephen]

On Sunday, February 10, 2013 9:57:20 AM UTC-6, Sebastian Krebs wrote:

 

But in short: Why do you invest your precious time to to change a working system, just because "its ugly"? Usually you don't need to look into the "vendor/"-folder, that is something composer takes care for you, so at the end it doesn't really care, whether it is ugly, or not ;)

Made me laugh. Well, if I had an answer to that, then I could probably start understanding why I am so particular with my coding format, names of parameters, my need for the data model to be pristine, that my code is compliant with rules and so forth. In the end, some time with a psychiatrist might yield an answer like I want *something* in my world to "be right" ... ;-)

I understand your point. My answer - I don't know why I care, but I do =)

[Sebastian Krebs]

2013/2/10 James Gilliland <necl...@gmail.com>

That does seem like a sort of cop out. We never need to debug other peoples code right?

I said "usually". Of course we need to step into foreign code from time to time, but for this once-in-a-month debugging (or maybe twice) I don't think rewriting the whole dependency management makes much sense. 

On the other side: Imagine you have 50 or 80 dependencies (that is not so hard to get). Is it really better to have a 'vendor'-folder with 80 folders, where some are related (same vendor)?

 

Or dig in and see how an interface is defined or copy some boiler plate code?

Or just figure out the logic happening in some class so we understand how to properly use it.

An IDE can help ("Know your tools" ;)). A "[Strg]-[Click]" is not that hard. Or "Find Usages". Or "Jump to Class/File", or whatever. I don't know, when I stepped through the folders manually the last time :X

Btw you can even checkout the corresponding project separately, or open your IDE with the packages folder as root.

 

This is open source after all. Basically, I think the reason it keeps coming up because we /do/ have to interact with it.

We are still talking about folders, right? Are you (both) really that upset about a folder?! Remember, that you (not me: I use the keyboard :D) just save a single click.

Just because I forgot this in my first reply: Omitting the docs, tests and so on in the distribution package is a bad, bad, bad idea.

 

To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/W4WpLU6BK1gJ.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
github.com/KingCrunch

[Brett Bieber]

On Sun, Feb 10, 2013 at 9:46 AM, Amy Stephen <amyst...@gmail.com> wrote:

What are others doing? Is anyone as nitpicky as I am on these things? Assuming you agree it's bothersome, should there be a recommendation on a standard approach that others might benefit from?

If I'm understanding you correctly, the PEAR & Pyrus installers handle this similarly to how you describe. Individual packages are installed to a common directory with the PSR-0 .php files inter-leaved together. Upgrades and filename conflicts are managed by the installer, because it remembers which files belong to each package. This results in (typically) two PSR-0 compliant autoloadable directories for your application: one for the vendor dependencies, and one for your local application.

As for tests and docs, these are handled similarly — all the docs go together, all the tests together etc. It's simply a different approach to how the installer places the dependencies on the local filesystem. I've found that both approaches have advantages and disadvantages.

--
Brett Bieber

[Daniel Ribeiro Gomes]

I do have to agree with Amy in some points.

Why does Symfony has in its components the Tests folder inside the namespace structure of src/, instead of outside of it, in a separate tests/ folder?

Daniel Ribeiro Gomes Pereira

Twitter | Facebook | LinkedIn

iPhone: +55 (48) 9111-0931

2013/2/10 Brett Bieber <brett....@gmail.com>

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

[Sebastian Krebs]

2013/2/10 Daniel Ribeiro Gomes <drgo...@gmail.com>

I do have to agree with Amy in some points.

Why does Symfony has in its components the Tests folder inside the namespace structure of src/, instead of outside of it, in a separate tests/ folder?

This are bundles.

 

Daniel Ribeiro Gomes Pereira

Twitter | Facebook | LinkedIn

iPhone: +55 (48) 9111-0931

2013/2/10 Brett Bieber <brett....@gmail.com>

On Sun, Feb 10, 2013 at 9:46 AM, Amy Stephen <amyst...@gmail.com> wrote:

What are others doing? Is anyone as nitpicky as I am on these things? Assuming you agree it's bothersome, should there be a recommendation on a standard approach that others might benefit from?

If I'm understanding you correctly, the PEAR & Pyrus installers handle this similarly to how you describe. Individual packages are installed to a common directory with the PSR-0 .php files inter-leaved together. Upgrades and filename conflicts are managed by the installer, because it remembers which files belong to each package. This results in (typically) two PSR-0 compliant autoloadable directories for your application: one for the vendor dependencies, and one for your local application.

As for tests and docs, these are handled similarly — all the docs go together, all the tests together etc. It's simply a different approach to how the installer places the dependencies on the local filesystem. I've found that both approaches have advantages and disadvantages.

--
Brett Bieber

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
github.com/KingCrunch

[Amy Stephen]

Brett and Daniel - thanks to each for your response. =)

I am going to really simplify my first post so the main points are clear.

My primary concern is the installation results in two additional layers of directories that serve no purpose.

My suggest is a slightly different approach to creating package repositories and using class map arrays for testing packages. With those changes, no additional directory layers result following the installation.

Here's an image of an example of what that directory structure could look like to accomplish this goal:

http://s7.postimage.org/7ar0rbvmz/Screen_shot_2013_02_10_at_9_04_50_AM.png

Again, thanks!

[Daniel Ribeiro Gomes]

No, not bundles, but components.

Check any component, like HttpFoundation, Config or Validator.

They all have the Test namespace inside the main namespace, within the src/ directory.

To me, that doesn't make a whole lot of sense.

I'd put the tests inside a separate folder from the src/, such as a tests/ directory.

Daniel Ribeiro Gomes Pereira

Twitter | Facebook | LinkedIn

iPhone: +55 (48) 9111-0931

2013/2/10 Sebastian Krebs <kreb...@gmail.com>

[Florin Patan]

It does so because the Components of which Symfony2 is made of

are available as standalone components, like this:

https://github.com/symfony/HttpFoundation

So if you are to use HttpFoundation without the rest of the framework

you can still have have tests and so on.

You can search in the history of Symfony2 repo as there was a

PR/issue opened about this I about 1.5 years ago, or so.

Regards,

Florin

[Gábor Fási]

This blogpost was published about two weeks ago. The author shares
your concern and has a possible solution:
https://igor.io/2013/01/23/autoload-insanity.html

--
Gábor

[Amy Stephen]

Brilliant! Thank you Gábor, I'm going to read it closely, but at quick glance, I can already see the same issues and suggestions raised. Appreciate you sharing this.

[Sebastian Krebs]

2013/2/10 Daniel Ribeiro Gomes <drgo...@gmail.com>

No, not bundles, but components.

Check any component, like HttpFoundation, Config or Validator.

They all have the Test namespace inside the main namespace, within the src/ directory.

To me, that doesn't make a whole lot of sense.

I'd put the tests inside a separate folder from the src/, such as a tests/ directory.

Well, you are right. But at the end it doesn't really matter :)

--
github.com/KingCrunch

[Florin Patan]

Hi Amy,

I think this would be better suited for Composer ML rather that FIG, at

least if I understand this right.

I'm not sure why Composer took the decision of having such a 'strage'

folder structure for the vendor directory but like others mentioned, it's

really a small issue when using a proper IDE (from the screenshots

I see you do, PHPStorm 5.0.4 if I'd have to take a guess).

As a solution, maybe Composer could drop the lowercase vendor/module

lowercase from prefix of installed packages but what would mean it

would also need to perform additional processing of packages like

locating if the sources are in src/, lib/, other_folder/ or not folder before

the Vendor\Module\Sources path. It could be done, but Jordi or someone

else from Composer would be much better at explaining this.

Best regards,

Florin

[Amy Stephen]

Hey Floran - thanks for your response.

My suggestion would not require any changes to Composer or Packager or the PSR-0 standard.

My proposal is to simply create the package (component for Symfony users) repository like this:

http://s7.postimage.org/7ar0rbvmz/Screen_shot_2013_02_10_at_9_04_50_AM.png

Then, unit testing would need the class map (since two folders are gone.)

But, after installation, the folders would be in place -- but only one time.

My proposal is not suggesting any programming changes, or standards changes, just a change in practice with how we create those repositories.

Let's set aside the issue of the test files as it's not the primary point.

Thanks!

[Amy Stephen]

Florin* not Floran. So sorry!

[justin]

Let me provide a counterpoint:

The deeply nested folders are actually *ideal* for any editor implementing "Cmd+T"-style fuzzy quick open — a list which includes a few you might have heard of: Sublime Text, Coda, TextMate (with a plugin), Eclipse (with a plugin), Vim and even GitHub.

To find the `Symfony/Component/HttpFoundation/JsonResponse.php` file, hit the "quick open" hotkey and type `s/c/h/json`. Or `Symfony/Component/HttpFoundataion/JsonResponse` if you're not into the whole brevity thing.

This only works because the files are in a PSR-0 compatible folder structure. If they weren't, the only way to quickly open JsonResponse.php would be to use the Composer vendor or package name, which usually isn't a perfect map to the namespace and class name. But a PSR-0 compatible folder structure is *guaranteed* to be a direct map.

--j

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/ZVR_4gVMoIkJ.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
http://justinhileman.com

[Amy Stephen]

Justin -

To clarify, I like:

`Symfony/Component/HttpFoundation/JsonResponse.php`

That is what my proposal would produce.

Unfortunately, what happens today is this:

`symfony/component/Symfony/Component/HttpFoundation/JsonResponse.php`

My suggestion is a procedural change in the folder structure for packages, a long with using class maps (not dynamic class loading) for unit testing. That change results in Composer and Packagist producing the first path.

Recommend reading https://igor.io/2013/01/23/autoload-insanity.html and the comments https://gist.github.com/igorw/4600419

Thanks much!

[justin]

On Sun, Feb 10, 2013 at 3:06 PM, Amy Stephen <amyst...@gmail.com> wrote:

Justin -

To clarify, I like:

`Symfony/Component/HttpFoundation/JsonResponse.php`

That is what my proposal would produce.

Unfortunately, what happens today is this:

`symfony/component/Symfony/Component/HttpFoundation/JsonResponse.php`

Actually, the current path is:

    vendor/symfony/http-foundation/Symfony/Component/HttpFoundation/JsonResponse.php

And your recommendation would change that to:

    vendor/symfony/http-foundation/JsonResponse.php

Your idea works as long as the composer vendor and package names are exactly equal to the first two levels in the project namespace, and as long as the package's classes start at the third level, and as long as the composer packages use camel case and capitalized vendor and package names. The problem is, these assumptions don't hold for a vast majority of projects I've used, and I'd guess that they don't hold for a majority of packages available on Packagist. Also, the last assumption is in direct violation of the Composer best practices for package names, so we can include an additional assumption: it requires a case-insensitive filesystem as well.

vs

 

My suggestion is a procedural change in the folder structure for packages, a long with using class maps (not dynamic class loading) for unit testing. That change results in Composer and Packagist producing the first path.

Recommend reading https://igor.io/2013/01/23/autoload-insanity.html and the comments https://gist.github.com/igorw/4600419

Yep. I've read them :)

 --j

[Amy Stephen]

Good, I feel like we are on the same track. Going to respond inline.

On Sun, Feb 10, 2013 at 5:20 PM, justin <jus...@justinhileman.info> wrote:

Actually, the current path is:

    vendor/symfony/http-foundation/Symfony/Component/HttpFoundation/JsonResponse.php

And your recommendation would change that to:

    vendor/symfony/http-foundation/JsonResponse.php

Was going from memory, there, but you are right. That's the complexity I would like to get rid of. I am fine with the PSR-0 namespace. I do not like the extra layers that get added as a result of our best practices, tools, and gitHub.
 

Your idea works as long as the composer vendor and package names are exactly equal to the first two levels in the project namespace, and as long as the package's classes start at the third level,

And, to be fair, that is the standard. If projects deviate from that, then, other things would result.
 

 and as long as the composer packages use camel case and capitalized vendor and package names.

That is another minor issue that I didn't raise. It is also "fixed" with my proposed approach.
 

The problem is, these assumptions don't hold for a vast majority of projects I've used, and I'd guess that they don't hold for a majority of packages available on Packagist.

I looked at many this past week and I think there is at least growing conformance.

But, would you agree for projects that follow the PSR-0 folder standard and use the recommended installation tools, it would be good to aim for no additional layers?
 

Also, the last assumption is in direct violation of the Composer best practices for package names, so we can include an additional assumption: it requires a case-insensitive filesystem as well.

Now, personally, I believe that needs to be reconsidered and aligned with the PSR-0 standard.


The take home message is - don't store the "node string" in your package repository that you will have automatically added by the installer. That could be 2 layers, that could be 3 layers, regardless, don't build it into the repository folders for the package. If you avoid doing that -- and use a class map for testing (since the folders aren't there) - you will NOT get the duplicated nodes from Composer/Packagist.

Thanks for the clarity in your explanation and the images, Justin.

[justin]

On Sun, Feb 10, 2013 at 3:35 PM, Amy Stephen <amyst...@gmail.com> wrote:

Good, I feel like we are on the same track. Going to respond inline.

On Sun, Feb 10, 2013 at 5:20 PM, justin <jus...@justinhileman.info> wrote:

Actually, the current path is:

    vendor/symfony/http-foundation/Symfony/Component/HttpFoundation/JsonResponse.php

And your recommendation would change that to:

    vendor/symfony/http-foundation/JsonResponse.php

Was going from memory, there, but you are right. That's the complexity I would like to get rid of. I am fine with the PSR-0 namespace. I do not like the extra layers that get added as a result of our best practices, tools, and gitHub.
 

Your idea works as long as the composer vendor and package names are exactly equal to the first two levels in the project namespace, and as long as the package's classes start at the third level,

And, to be fair, that is the standard. If projects deviate from that, then, other things would result.

It's not the standard though. See pimple/pimple, monolog/monolog, mustache/mustache, twig/twig, zendframework/zendframework, symfony/symfony, symfony/http-foundation, etc. There's no requirement in PSR-0 to have a package name at all, just a vendor name. In fact, it's rather common for standalone libraries to use their vendor name as their package name; see: Monolog, Mustache, Pimple and Twig.

 

 

 and as long as the composer packages use camel case and capitalized vendor and package names.

That is another minor issue that I didn't raise. It is also "fixed" with my proposed approach.
 

The problem is, these assumptions don't hold for a vast majority of projects I've used, and I'd guess that they don't hold for a majority of packages available on Packagist.

I looked at many this past week and I think there is at least growing conformance.

Nope. See above. The vendor + package for Composer do are not required to — and often do not at all — map to two levels of PHP namespace. And that's perfectly fine.

In the case of Monolog, Pimple, Twig and Mustache, the vendor name is used as both vendor and package in Composer, but duplicating that in the PHP namespace would be absurd. In the case of symfony/http-foundation, the Composer name is right, because this is Symfony's "HTTP foundation" package. The PHP namespace `Symfony/Component/HttpFoundation` is also correct, since Symfony has enough packages that they want to namespace them under a "type" level. Both of these approaches are allowed and even recommended by Composer and PSR-0.

Composer package names are not required to, and often *should* not, map directly to PHP namespaces. And in my opinion, this is the right way to do it.

 

But, would you agree for projects that follow the PSR-0 folder standard and use the recommended installation tools, it would be good to aim for no additional layers?

I would not agree.

Because the only way to do this and maintain the namespace-to-folder-name mapping would be to *ignore* the Composer package vendor and name, and use the PHP namespace as the full vendor path. i.e. the way PEAR installs packages. But this is a decidedly worse way of doing it.

--j

[Amy Stephen]

On Sun, Feb 10, 2013 at 5:20 PM, justin <jus...@justinhileman.info> wrote:
>
>
>

> Actually, the current path is:
>
> vendor/symfony/http-foundation/Symfony/Component/HttpFoundation/JsonResponse.php
>
>
> And your recommendation would change that to:
>
> vendor/symfony/http-foundation/JsonResponse.php
>
> Your idea works as long as the composer vendor and package names are exactly equal to the first two levels in the project namespace, and as long as the package's classes start at the third level, and as long as the composer packages use camel case and capitalized vendor and package names.

Actually, Justin, I want to re-address this part of your comments, it
really is the heart of the matter. I see you posted again - but I
think you might agree with this.

1. Name your Packagist package Vendor and Package name for the first
two nodes of the name space.

2. Do not use the target-dir portion of the composer data.

3. Do not include the first two levels of folders in your package repository.

Doing that will work every time.

To test using Symfony's example:

1. Composer Vendor Package --

symfony/componser/

2. Remove the Composer target-dir

"target-dir": "Symfony/Component/HttpFoundation",

3. Do not include the Vendor Package name in the folder structure of
the package.

Symfony does not do this.


To "fix" the Symfony example, all that must be done is to remove the
value from the Composer target-dir.

[Amy Stephen]

>
> To test using Symfony's example:
>
> 1. Composer Vendor Package --
>
> symfony/componser/
>

Correction:

symfony/httpfoundation

[Daniel Ribeiro Gomes]

And if there was a separate tests/ directory, wouldn't that be achieved as well?

Daniel Ribeiro Gomes Pereira

Twitter | Facebook | LinkedIn

iPhone: +55 (48) 9111-0931

2013/2/10 Florin Patan <flori...@gmail.com>

To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/yIGSz-GzyhwJ.

[justin]

On Sun, Feb 10, 2013 at 4:07 PM, Amy Stephen <amyst...@gmail.com> wrote:

Actually, Justin, I want to re-address this part of your comments, it
really is the heart of the matter. I see you posted again - but I
think you might agree with this.

Actually, you didn't address my last email at all.

Symfony has three types of packages: Bundles, Components and Bridges. You can see them here:

https://github.com/symfony/symfony/tree/master/src/Symfony

Using `symfony/component` as the package name wouldn't work, because there are a *lot* of symfony components:

https://github.com/symfony/symfony/tree/master/src/Symfony/Component

... each of which has its own Composer package.

Using `symfony/http-component` is great, but requiring that to match the PHP namespace would force Symfony to mix their Bundles, Components and Bridges together into one big mess, which would make things decidedly worse for them.

At the other end of the spectrum, what would you suggest Monolog use as the "package" namespace level?

http://github.com/Seldaek/monolog/blob/master/src/Monolog/Logger.php

Should that class be `Monolog/Monolog/Logger`?

There isn't a second level, because it isn't needed. Monolog is a standalone library, and its vendor name is the same as its package name. Forcing it to use another level of namespace just for the sake of matching its composer package name would be just as bad for them as forcing Symfony to dump all its packages directly into the Symfony namespace rather than splitting them into sub-namespaces.

I think the problem is that you're assuming a 1:1 map from PHP namespace to Composer package name. That assumption does not hold, and is a sub-optimal requirement for both of the cases I outlined above. And for what it's worth, most packages fall into one or the other of these cases.

--j 

[Amy Stephen]

On Sun, Feb 10, 2013 at 5:52 PM, justin <jus...@justinhileman.info> wrote:
>
>
>
> It's not the standard though. See pimple/pimple, monolog/monolog,
> mustache/mustache, twig/twig, zendframework/zendframework, symfony/symfony,
> symfony/http-foundation, etc. There's no requirement in PSR-0 to have a
> package name at all, just a vendor name. In fact, it's rather common for
> standalone libraries to use their vendor name as their package name; see:
> Monolog, Mustache, Pimple and Twig.

To be fair, this is a separate issue and one that probably should be addressed by Composer during the install. (If the first two nodes match, use it once.)

OK, got it, Justin. I need to think about your points a bit. What would probably help would be to see examples of where a package should not be the Vendor/Package namespace nodes. That might be the missing piece for me to agree with your point of view.

I do believe I understand your perspective, but at this time, I really do not see any compelling reason to leave all that room for projects to inject more layering. Frankly, I'm convinced most end up with extra layers simply because they are not aware of how their decisions impact the folders created. Could be wrong though.

But, you gave me lots to think on and the Pear reference will be reviewed.

Thanks!

[Amy Stephen]

On Sun, Feb 10, 2013 at 6:24 PM, justin <jus...@justinhileman.info> wrote:

On Sun, Feb 10, 2013 at 4:07 PM, Amy Stephen <amyst...@gmail.com> wrote:

Actually, Justin, I want to re-address this part of your comments, it
really is the heart of the matter. I see you posted again - but I
think you might agree with this.

Actually, you didn't address my last email at all.

Good god! Trying to keep up! Was hitting send when you emailed - but I did respond. Old woman here, go slow. Patience young fella!
 

Symfony has three types of packages: Bundles, Components and Bridges. You can see them here:

https://github.com/symfony/symfony/tree/master/src/Symfony

Using `symfony/component` as the package name wouldn't work, because there are a *lot* of symfony components:

https://github.com/symfony/symfony/tree/master/src/Symfony/Component

... each of which has its own Composer package.

Using `symfony/http-component` is great, but requiring that to match the PHP namespace would force Symfony to mix their Bundles, Components and Bridges together into one big mess, which would make things decidedly worse for them.

Symfony can do whatever the project understands to be best -- I admire that project greatly and I am certain they have reasons for every decision they make.

I am only sharing my opinion as someone who uses Symfony software.

At the other end of the spectrum, what would you suggest Monolog use as the "package" namespace level?

http://github.com/Seldaek/monolog/blob/master/src/Monolog/Logger.php

Should that class be `Monolog/Monolog/Logger`?

That's exactly what happens during the install, yes.

Looks like we found one area of agreement.
 

There isn't a second level, because it isn't needed. Monolog is a standalone library, and its vendor name is the same as its package name. Forcing it to use another level of namespace just for the sake of matching its composer package name

Install it -- that's what happens. Not sure who you are arguing with, not me.
 

would be just as bad for them as forcing Symfony to dump all its packages directly into the Symfony namespace rather than splitting them into sub-namespaces.

Not trying to force Symfony to do anything.
 

I think the problem is that you're assuming a 1:1 map from PHP namespace to Composer package name. That assumption does not hold, and is a sub-optimal requirement for both of the cases I outlined above. And for what it's worth, most packages fall into one or the other of these cases.

The problem is, and I am far from alone on this, the folders are growing exponentially. Being able to cut those back and still retain good information would be preferred by some of us.

[justin]

On Sun, Feb 10, 2013 at 4:34 PM, Amy Stephen <amyst...@gmail.com> wrote:

To be fair, this is a separate issue and one that probably should be addressed by Composer during the install. (If the first two nodes match, use it once.)

OK, got it, Justin. I need to think about your points a bit. What would probably help would be to see examples of where a package should not be the Vendor/Package namespace nodes. That might be the missing piece for me to agree with your point of view.

Those *were* the examples.

    Monolog

    Twig

    Mustache

Each of these is a standalone library. The vendor for each is the same as the package. Meaning, their classes are currently:

    Monolog/Logger

    Twig_Environment

    Mustache_Engine

To work with your suggested directory structure, they would have to be:

    Monolog/Monolog/Logger

    Twig_Twig_Environment

    Mustache_Mustache_Engine

What purpose would this additional level serve? None, save for forcing the namespace to match the Composer package name.

If you want more examples, check out: silex/silex, swiftmailer/swiftmailer, phpunit/phpunit, pagerfanta/pagerfanta, slim/slim, phpoption/phpoption, phpcollection/phpcollection, guzzle/guzzle, phing/phing, behat/behat, solarium/solarium, imagine/imagine, propel/propel, etc.

There are literally thousands of cases exactly like this.

 

I do believe I understand your perspective, but at this time, I really do not see any compelling reason to leave all that room for projects to inject more layering. Frankly, I'm convinced most end up with extra layers simply because they are not aware of how their decisions impact the folders created. Could be wrong though.

Symfony adds another layer because it makes sense for their project. Because that way you know there's a difference between

    Symfony/Component/HttpFoundation

and

    Symfony/Bundle/SecurityBundle

They use the namespace to indicate that these are, in fact, two different areas of functionality in the framework. So given that, you know that

    Symfony/Component/Config

... is probably more related to HttpFoundation than SecurityBundle, right? Because it's in the same sub-namespace. They use the namespace as a namespace.

Again, your difficulty arises because you're assuming a 1:1 mapping between PHP namespace and Composer name.

This mapping simply does not exist. It should not exist. It was never intended to exist.

The cases where they happen to match are just that: coincidences.

-- j

[justin]

On Sun, Feb 10, 2013 at 4:45 PM, Amy Stephen <amyst...@gmail.com> wrote:

On Sun, Feb 10, 2013 at 6:24 PM, justin <jus...@justinhileman.info> wrote:

On Sun, Feb 10, 2013 at 4:07 PM, Amy Stephen <amyst...@gmail.com> wrote:

Actually, Justin, I want to re-address this part of your comments, it
really is the heart of the matter. I see you posted again - but I
think you might agree with this.

Actually, you didn't address my last email at all.

Good god! Trying to keep up! Was hitting send when you emailed - but I did respond. Old woman here, go slow. Patience young fella!

Sorry, I assumed you were responding to my most recent email. I'll slow down :)

--j

[Amy Stephen]

It's okay, Justin. It's good to challenge thinking and that's what you were doing. It's the right thing to do. As a result, I have been reading and looking this over again. Making certain I have things clear in my mind.

I am confident -- we cannot implement our standard.

Given everything I have read, everything suggest this to be the intended standard:

http://example.com/vendor/Molajo/Filters/Int

But, the best anyone can achieve through careful planning of the folder setup on their github repository, the way they use Composer and Packagist, the rules imposed in those environments, is this:

http://example.com/vendor/molajo/filters/Molajo/Filters/Int

Now, say what you will about projects who want more layers in their namespace, I don't even care to debate it. They want 20 nodes, fine. But can we can at least agree that those who wish to implement according to the examples on the standard should be able to do so?

http://example.com/vendor/Molajo/Filters/Int

The environment, as it stands, cannot produce this. In my opinion, we are not able to implement what was intended in the standard. If you don't agree, fine. But, you cannot disagree that we are unable to produce the examples in the standard.

I believe there is a problem and we should try to ensure people can follow the rules in the standard. Does that seem reasonable? If not, I'm stumped and returning to my code. That just wouldn't make sense to me.

[Phil Sturgeon]

I'm getting into this one a little late.

So far it seems that the main problems are these "Two extra folders", but thats just not true.

Often I see packages that do this:

• src/Vendor/Package.php
  
• src/Vendor/Package/Other/Stuff.php
  

If we removed these "two extra folders" then this would break those applications.

Again, as has been said a bunch of times, we'd also be enforcing naming conventions on the exact name of the package - and these package names should be able to support classmap, PSR-0 or BobsRandomStandard if bobs random standard gets enough support to bake into Composer. Remember, Composer is not the only package management system, PSR-0 is not the only standard, and Composer is technically nothing to do with the PHP-FIG. They all work together, but we can't just go around telling everyone how to do everything, just to get rid of "two extra folders".

As for unit-testing, why on earth would I NOT want their unit tests?! Do you expect me to simply trust that everything works and that they definitely didn't forget to set up travis-ci or jenkins for their last build? I'd much rather run my little bash script that goes through hunting for and running as many phpunit.xml files as it can find, to ensure my code is actually going to work when I deploy it.

With all due respect to everyone involved, this whole conversation amounts to "there are extra folders and files and i dont like it", but they all have reasons for being there. Messing around with this does not solve a problem, and could potentially cause a LOT of issues.

[Amy Stephen]

Phil -

These are the examples from the standard.

None of these can be produced in the current environment.

• \Doctrine\Common\IsolatedClassLoader => /path/to/project/lib/vendor/Doctrine/Common/IsolatedClassLoader.php
• \Symfony\Core\Request => /path/to/project/lib/vendor/Symfony/Core/Request.php
• \Zend\Acl => /path/to/project/lib/vendor/Zend/Acl.php
• \Zend\Mail\Message => /path/to/project/lib/vendor/Zend/Mail/Message.php

Is that acceptable?

If so, should the examples be changed to reflect what is possible?

Or, should just let people figure it out on their own?

[justin]

But `vendor` isn't a shared PSR-0 root directory. There's an individual PSR-0 root directory for each package. And it's up to the package to define exactly what directory that is:

    `Doctrine\Common` has one at `vendor/doctrine/common/lib`

    `Symfony\Component\HttpFoundation` has one at `vendor/symfony/http-component`

    `Monolog` has one at `vendor/monolog/monolog/src`

*Those* directories are the ones that the examples are talking about. Not the `vendor` directory itself.

--j

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/4WEnJT6aaCkJ.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
http://justinhileman.com

[Amy Stephen]

Another group with members who are actually responsible for these applications are, and have been, discussing a similar topic.

Might be good to let this set now and see what conclusions they reach.

Thanks.

[Drak]

I mentioned this already during the PSR-3 ancillary discussions that many newer projects are doing away with src/ and tests/ where it makes sense - in some cases it doesnt. You can look at some repos like https://github.com/fabpot/Sami for example - a LOT of new projects are doing this. Having tests as part of the package also means doesnt need to make any special autoloading since tests just use the composer autoloader it's done. Tests are very much arguable part of the documentation as they help developers to understand the package. So we're even doing this repo layout with PSR-3 see the https://github.com/php-fig/log repo.

However I have to strongly disagree about worrying about how composer lays out vendors. It's very organised and your IDE will just jump to the class / method definitions with something like a keypress (e.g. F3). There is nothing to standardise here anyway since composer has taken the lead and become a defacto standard. It works, people are happy with with it and everyone is using it. QED.

Regards,

Drak

[Phil Sturgeon]

These are the examples from the standard.

None of these can be produced in the current environment.

• \Doctrine\Common\IsolatedClassLoader => /path/to/project/lib/vendor/Doctrine/Common/IsolatedClassLoader.php
• \Symfony\Core\Request => /path/to/project/lib/vendor/Symfony/Core/Request.php
• \Zend\Acl => /path/to/project/lib/vendor/Zend/Acl.php
• \Zend\Mail\Message => /path/to/project/lib/vendor/Zend/Mail/Message.php

Is that acceptable?

I'm sorry Amy but I have no idea what you are talking about. 

lib/ is a folder (much like src) where people store the PSR-0 code for a single component, so it would look more like this:

• \Doctrine\Common\IsolatedClassLoader => ./vendor/doctrine/common/lib/Doctrine/Common/IsolatedClassLoader.php
  

Only the lib/ or src/ folders are PSR-0, so by trying to make THE ENTIRE package PSR-0 you confuse everything. I want to bundle tests/ migrations/ assets/ examples/ and a README.md. Should my README be autoloadable? :p

I genuinely think you are missing a core piece of understanding about this, and are trying to oversimplify things to a level where they would be detrimental to functionality that most people want and understand.

[Amy Stephen]

Phil - those paths you are objecting too are copied and pasted from the Standard.

[Evert Pot]

>
> Phil - those paths you are objecting too are copied and pasted from the Standard.

Those are just intended as a 'generic' vendor directory, not specific to composer.. they're just examples.

That stuff actually pre-dates composer.

Evert

[Amy Stephen]

Evert -

That makes sense.

The impact of how Composer works and the more "lofty" concepts for the standard that proceed implementation are slightly different.

That doesn't mean it's right or wrong, but it creates a bit of confusion. Simple as that.

Thanks for your response. Much appreciated.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

[Amy Stephen]

A number of times, I have tried to make the point that there is a problem implementing the standard, given the examples, given the implications of the current environment.

What I hope for is clarity for those who work to implement this standard.

This discussion has been helpful, even though it has been challenging, and I have been reminded of the importance of being clear and to the point. My approach created confusion as many responses were then to cursory points rather than the central theme.

That is my fault and I apologize for that.

I happen to believe that this namespacing standard and the work on Interfaces are going to change the PHP community in a very positive way. That's why I care about the clarity. I want all PHP developers to know how this works and to get involved.

Given the assistance of those of you who have participated, I wrote a little FAQ, of sorts, that helps clarify how using Composer to implement the PSR-0 works. The nuts and bolts of it all. Please read and fork it to improve it and/or post in the comments. I think it could help others get involved.

https://gist.github.com/AmyStephen/4756621

Thanks for your patience and help.

[Christian Riesen]

Terribly sorry for hopping into this now, but I have, after reading all of it, not found the technical aspect of this. If it's pure esthetics, we can discuss that till the end of time + 1 millisecond. But where is the technical aspect of it?

If I want to find a classes content I can either, in pretty much any useable IDE today click the class with an operating key pressed and it jumps into it, no matter where it is nested. If I'm interested in more or don't want to stress my IDE of choice too much with that, I look up the github repo and look in there. Both are very valid and don't stop me from going to dig into the underbelly of the vendor directory.

The way composer handles it, with the package and vendors names actually helps, because in many cases whenever I need to look at the content of the vendor directory, I usually have just looked at the composer file, which then reflects the package in question. It also splits things apart, like Doctrine and Symfony pieces, that would otherwise be mushed into one large blob.

I see no significant overhead here in the extra directories. I see no problems with executing the code therein.

I can get more information (tests, documentation, ressources, examples, etc) with this structure which also has saved me so far at least a month of work already and I'm only using this setup for half a year now.

To give you another wonderful example, I bugged William Durand in the first steps with composer, on how can I get one of the custom bundles I created for my company to be put into the src folder of symfony, you know, for autoloading and easier editing... His answer was "Why would you want to?" The lightbulb has been shining ever since and saved the company I work for huge headaches.

So it comes down to that question, why would you want to?

Greetings,
Christian Riesen

[Amy Stephen]

On Fri, Feb 15, 2013 at 2:59 PM, Christian Riesen <chris....@gmail.com> wrote:

Terribly sorry for hopping into this now, but I have, after reading all of it, not found the technical aspect of this. If it's pure esthetics, we can discuss that till the end of time + 1 millisecond. But where is the technical aspect of it?

If I want to find a classes content I can either, in pretty much any useable IDE today click the class with an operating key pressed and it jumps into it, no matter where it is nested. If I'm interested in more or don't want to stress my IDE of choice too much with that, I look up the github repo and look in there. Both are very valid and don't stop me from going to dig into the underbelly of the vendor directory.

Dear God, why did I bother?

Actually, the more I think about it, I just *love* the duplication in the paths like this:

molajo/filters/Molajo/Filters

In a sense, it's reminder of where I am. 

Maybe some people need to see it twice before it sinks in.

The way composer handles it, with the package and vendors names actually helps, because in many cases whenever I need to look at the content of the vendor directory, I usually have just looked at the composer file, which then reflects the package in question. It also splits things apart, like Doctrine and Symfony pieces, that would otherwise be mushed into one large blob.

I see no significant overhead here in the extra directories. I see no problems with executing the code therein.

I can get more information (tests, documentation, ressources, examples, etc) with this structure which also has saved me so far at least a month of work already and I'm only using this setup for half a year now.

To give you another wonderful example, I bugged William Durand in the first steps with composer, on how can I get one of the custom bundles I created for my company to be put into the src folder of symfony, you know, for autoloading and easier editing... His answer was "Why would you want to?" The lightbulb has been shining ever since and saved the company I work for huge headaches.

So it comes down to that question, why would you want to?

Greetings,
Christian Riesen

On Monday, February 11, 2013 8:10:20 PM UTC+1, Amy Stephen wrote:

A number of times, I have tried to make the point that there is a problem implementing the standard, given the examples, given the implications of the current environment.

What I hope for is clarity for those who work to implement this standard.

This discussion has been helpful, even though it has been challenging, and I have been reminded of the importance of being clear and to the point. My approach created confusion as many responses were then to cursory points rather than the central theme.

That is my fault and I apologize for that.

I happen to believe that this namespacing standard and the work on Interfaces are going to change the PHP community in a very positive way. That's why I care about the clarity. I want all PHP developers to know how this works and to get involved.

Given the assistance of those of you who have participated, I wrote a little FAQ, of sorts, that helps clarify how using Composer to implement the PSR-0 works. The nuts and bolts of it all. Please read and fork it to improve it and/or post in the comments. I think it could help others get involved.

https://gist.github.com/AmyStephen/4756621

Thanks for your patience and help.

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/oGLPiaA3azQJ.

[Paul Dragoonis]

Hi Amy,

The model of PSR0 implies we need to have an absolute path relation to the class name, so once you're into ./molajo/filters/src/ then you need a further /Molajo/Filters/ in order to transform the class name. There's nothing we can do to change this.

If you were really passionate it about it you could have a molajo general folder with sub-paths inside it which is doable within composer. Each Filters, Users and Something could be sub-packages if you wanted them to be split up into composer packages.

./vendor/molajo/src/Molajo/Filters/

./vendor/molajo/src/Molajo/Users/

./vendor/molajo/src/Molajo/Something/

Hope this helps.

Many thanks,

Paul

[Amy Stephen]

On Fri, Feb 15, 2013 at 3:55 PM, Paul Dragoonis <drag...@gmail.com> wrote:

Hi Amy,

The model of PSR0 implies we need to have an absolute path relation to the class name, so once you're into ./molajo/filters/src/ then you need a further /Molajo/Filters/ in order to transform the class name. There's nothing we can do to change this.

Yea, Paul, sorry, but you do not understand the point. In fact, the molajo/filers/src is not part of the standard, it's just the convention that was introduced by the logging PSR class. Unless you want the duplication, I recommend against using that folder structure.
 

If you were really passionate it about it

Passionate? =)

No, I was just hoping to help.

You see, I was confused -- For the life of me, I could get the path described in the standard. So, I dug into it and figured out why. Once I understood all of the implications, I was hoping to save others time and frustration.
 

you could have a molajo general folder with sub-paths inside it which is doable within composer. Each Filters, Users and Something could be sub-packages if you wanted them to be split up into composer packages.

./vendor/molajo/src/Molajo/Filters/

./vendor/molajo/src/Molajo/Users/

./vendor/molajo/src/Molajo/Something/

Hope this helps.

Nope, sorry, doesn't help, at all. Doesn't even describe the problem. In fact, your suggestions are not possible or make the path deeper and further from the examples in the standard.

#1 - Composer is always going to add two layers in lower case, so unless you name your project "src" - you can't get even get '/vendor/molajo/src'. So, that's just wrong info.

#2 - Your approach just makes the path longer by two *more* nodes. ;-)

I documented the process - at the bottom of the page - section "Advice to achieve the minimum path possible" I describe the three factors you need to keep in mind to get the shortest paths possible.

https://gist.github.com/AmyStephen/4756621
 

Many thanks,

Paul

I have had a few people contact me, thanking for the explanation. They had the same problem getting it right and finally just gave up. One person I know is planning to use the information User's Guide of sorts, so, hopefully, the explanation might help those who weren't involved but are trying to comply.

Many thanks to you, as well.
Amy

 

[Brett Bieber]

On Fri, Feb 15, 2013 at 3:55 PM, Paul Dragoonis <drag...@gmail.com> wrote:

Hi Amy,

The model of PSR0 implies we need to have an absolute path relation to the class name, so once you're into ./molajo/filters/src/ then you need a further /Molajo/Filters/ in order to transform the class name. There's nothing we can do to change this.

If you were really passionate it about it you could have a molajo general folder with sub-paths inside it which is doable within composer. Each Filters, Users and Something could be sub-packages if you wanted them to be split up into composer packages.

./vendor/molajo/src/Molajo/Filters/

./vendor/molajo/src/Molajo/Users/

./vendor/molajo/src/Molajo/Something/

I think Amy's complaint is really about the packaging and installation paths including the extra directories. This is really a fundamental difference in how the packaging process works and how the installer functions.

For a PEAR-installable package, PEAR and Pyrus would install these files to:

./vendor/php/Molajo/Filters/
./vendor/php/Molajo/Users/
./vendor/php/Molajo/Something/

likewise:
./vendor/php/Zend/Mail/
./vendor/php/Zend/Stdlib/

./vendor/php/PEAR2/HTTP/

This relies on the vendor namespace prefix of the PSR-0 class to provide the unique directory structure, and not the package name. Because there are no standards for other files, such as tests, data files, doc files etc, Pyrus DOES use the package name and channel to prefix those files:
./vendor/docs/pear2.php.net/PEAR2_HTTP_Request/examples/

or
./vendor/tests/pear2.php.net/PEAR2_HTTP_Request/

Like I said before, this is simply a different approach to packaging and how the installer places the files on the local filesystem.

--
Brett Bieber

[Amy Stephen]

Yes, Brett, thank you.

Since it is a new process, I also wasn't certain if anyone had actually put their finger on the problem. I spent time trying to understand and was hoping to point out that the paths were not in line with the standard - and why.

It was not a big deal to me but I hoped I could help others who might be confused.

On Fri, Feb 15, 2013 at 4:17 PM, Brett Bieber <brett....@gmail.com> wrote:

On Fri, Feb 15, 2013 at 3:55 PM, Paul Dragoonis <drag...@gmail.com> wrote:

Hi Amy,

The model of PSR0 implies we need to have an absolute path relation to the class name, so once you're into ./molajo/filters/src/ then you need a further /Molajo/Filters/ in order to transform the class name. There's nothing we can do to change this.

If you were really passionate it about it you could have a molajo general folder with sub-paths inside it which is doable within composer. Each Filters, Users and Something could be sub-packages if you wanted them to be split up into composer packages.

./vendor/molajo/src/Molajo/Filters/

./vendor/molajo/src/Molajo/Users/

./vendor/molajo/src/Molajo/Something/

I think Amy's complaint is really about the packaging and installation paths including the extra directories. This is really a fundamental difference in how the packaging process works and how the installer functions.

Yes. (Although I didn't mean to sound like I was complaining and apologize if I did.)
 

For a PEAR-installable package, PEAR and Pyrus would install these files to:

./vendor/php/Molajo/Filters/
./vendor/php/Molajo/Users/
./vendor/php/Molajo/Something/

likewise:
./vendor/php/Zend/Mail/
./vendor/php/Zend/Stdlib/

./vendor/php/PEAR2/HTTP/

This relies on the vendor namespace prefix of the PSR-0 class to provide the unique directory structure, and not the package name.

And actually, the Composer/Packages rules *do* require the same PSR-0 vendor name and a package name -- so -- it could be reused.

That's why I thought it was just a mistake.
 

Because there are no standards for other files, such as tests, data files, doc files etc, Pyrus DOES use the package name and channel to prefix those files:
./vendor/docs/pear2.php.net/PEAR2_HTTP_Request/examples/

or
./vendor/tests/pear2.php.net/PEAR2_HTTP_Request/

Like I said before, this is simply a different approach to packaging and how the installer places the files on the local filesystem.

--
Brett Bieber

Thank you for hearing me.

[Paul Dragoonis]

Hi Amy,

I do understand the issue here now. To confirm you're pointing out that you see <package name> as unnecessary?

./vendor/<package name>/Molajo/Fliters/MyClass.php

If i'm not correct I apologise as I've jumped into this thread late and have TL;DR syndrome :-)

[Amy Stephen]

On Fri, Feb 15, 2013 at 4:34 PM, Paul Dragoonis <drag...@gmail.com> wrote:

Hi Amy,

I do understand the issue here now. To confirm you're pointing out that you see <package name> as unnecessary?

./vendor/<package name>/Molajo/Fliters/MyClass.php

If i'm not correct I apologise as I've jumped into this thread late and have TL;DR syndrome :-)

Now, tl;dr, I *totally* get, Paul. In fact, a few posts back I apologized for my first post and the approach - I should have kept it simple.

You're close - it is the two nodes: <PSR-0-Vendor-name>/<Composer-Package-name> that are duplicated in the install path.

But, as a result of this thread, I realize it's not a mistake that can be corrected like I had thought. It's just a function of what Composer requires as a key (lower case PSR-0 vendor name/and package name) and PSR-0 requiring those values in Camel-case.

And that's cool, I really do not care, I want to comply and lost time a lot of time trying to figure out the voodoo required to make the system build the paths in the example.

After this discussion, I see why. So, I documented how it works and why, hoping it might help the next person understand.

Next time, I will be more careful with my approach.

Thanks for your response.


 

[Paul Dragoonis]

Hi Amy,

I recommend you don't be careful, and to question things, keep pushing the envelope on this list and in general, it's not takes as pessimistic it just shows you care.

It's people with your enthusiasm to make things right that make software great.

Cheers,

Paul Dragoonis

[Paul Dragoonis]

takes = taken *

[Sebastian Krebs]

2013/2/15 Amy Stephen <amyst...@gmail.com>

On Fri, Feb 15, 2013 at 4:34 PM, Paul Dragoonis <drag...@gmail.com> wrote:

Hi Amy,

I do understand the issue here now. To confirm you're pointing out that you see <package name> as unnecessary?

./vendor/<package name>/Molajo/Fliters/MyClass.php

If i'm not correct I apologise as I've jumped into this thread late and have TL;DR syndrome :-)

Now, tl;dr, I *totally* get, Paul. In fact, a few posts back I apologized for my first post and the approach - I should have kept it simple.

You're close - it is the two nodes: <PSR-0-Vendor-name>/<Composer-Package-name> that are duplicated in the install path.

But, as a result of this thread, I realize it's not a mistake that can be corrected like I had thought. It's just a function of what Composer requires as a key (lower case PSR-0 vendor name/and package name) and PSR-0 requiring those values in Camel-case.

Hi,

Not directly, beside that it is often the case: The path is always the package name mentioned in the 'composer.json', that is itself always 'vendor/packagename' in lowercase [1]. In fact you can choose whatever you want [2], but if you don't want to confuse your users, you should indeed use the same names that you use in the first two levels of your PSR-0 namespaces :)

An popular example, that differs from this: Symfony2-framework (aka "symfony/symfony"). Because as a set of multiple packages it doesn't have a single 2nd-level-namespace.

Another one is the Symfony2 Demo-Application aka "symfony/symfony/framework-standard-edition"

Regards,

Sebastian

[1] I asked, why it must be lowercase and the answer was "to keep it simple" and to avoid problems with case-insensitive file systems. Must say I had many similar discussions directly with the developer (composer mailinglist) and I fear I didn't won one of them :D

[2] As far as I remember the "foo/bar"-notation is a requirement :X

--
github.com/KingCrunch

[Amy Stephen]

Boy, Paul, much "from the bottom of my heart" thanks.