Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move contents of app/ to / #584

Closed
webmozart opened this issue Aug 19, 2013 · 305 comments
Closed

Move contents of app/ to / #584

webmozart opened this issue Aug 19, 2013 · 305 comments

Comments

@webmozart
Copy link

@webmozart webmozart commented Aug 19, 2013

Original description:

Is there a reason why the phpunit.xml.dist is located in app/ and not in the root directory? Putting it in the root would save us from having to type -c app for every test.

@Tobion
Copy link
Member

@Tobion Tobion commented Aug 19, 2013

Duplicate of #501 and #325

@lyrixx
Copy link
Member

@lyrixx lyrixx commented Aug 19, 2013

I'm totally +1 with this ;)

@fabpot
Copy link
Member

@fabpot fabpot commented Aug 19, 2013

I've explained the reasons in the referenced PR/issues. Just moving the phpunit.xml.dist file does not make sense.

That said, I do agree that having the file in the root directory would be nice. But instead of just moving the file, we should re-discuss the app/ directory itself first.

Basically, the original idea was to be able to host more than one application in a Symfony project, or at least, provide the out-of-the-box flexibility to be able to do so. I'm not sure people are using this feature and frankly, I've never used it myself. If there is a consensus that it's not really needed to provide such a flexibility, the app/ directory does not make sense anymore and we should discuss the "ideal" directory structure for a project that always contains one application (it does not mean that you cannot have more than one app in a project, just that the default directory structure does not take that constraint into account).

@webmozart
Copy link
Author

@webmozart webmozart commented Aug 19, 2013

@fabpot I see. I think that people whose requirements are so special that they really need multiple apps per project should also be experienced enough to reconfigure Symfony. For the majority of other cases, one app per project (and thus the content of app/ moved to root) should be fine.

@fabpot
Copy link
Member

@fabpot fabpot commented Aug 22, 2013

Here is an alternative directory structure that get rid of the app/ directory:

├── cache
├── composer.json
├── composer.lock
├── console
├── logs
├── phpunit.xml.dist
├── src
│   ├── Acme
│   ├── AppCache.php
│   ├── AppKernel.php
│   ├── Resources
│       ├── config
│       └── views
│   ├── SymfonyRequirements.php
│   ├── autoload.php
│   ├── bootstrap.php.cache
│   └── check.php
├── vendor
└── web
@peterjmit
Copy link

@peterjmit peterjmit commented Aug 22, 2013

@fabpot 👍 Brings config file location inline with the bundles - feels a bit more intuitive.

@iansltx
Copy link

@iansltx iansltx commented Aug 22, 2013

Another vote in favor of this. The structure seems more consistent.

@lsmith77
Copy link
Contributor

@lsmith77 lsmith77 commented Aug 22, 2013

@fabpot I like your proposal because I think it places the key things a sysadmin would be interested in the root (notably the cache and log dirs). also the console script in the root also seems useful. i must admit i have often noticed people being a bit confused as to the difference of src and app and my answers didnt entirely convince myself either. i see no real downside .. even custom multi kernel apps are still possible just like before.

@ghost
Copy link

@ghost ghost commented Aug 22, 2013

I like that. It just makes more sense.

@tipyy
Copy link

@tipyy tipyy commented Aug 22, 2013

+1

@lsmith77
Copy link
Contributor

@lsmith77 lsmith77 commented Aug 22, 2013

BTW this is how I have structured multi kernel apps in the past and this would still be possible. In these multi kernel apps I always ended up deploying each kernel on a separate server so at least in production there would not be any issue with a single log and cache dir.

@youknowriad
Copy link

@youknowriad youknowriad commented Aug 22, 2013

I think it's a good structure, but i would prefer to extract the parameters.yml file (only from the src), maybe in a config folder or in the root. Cause often, this file is changed by sysadmins and it will be difficult for them to go find it in the src

@kimausloos
Copy link

@kimausloos kimausloos commented Aug 22, 2013

Couldn't src/ be renamed to app/? Since all code in src/ is used to make the application it seems more logical to me.

@mbadolato
Copy link
Contributor

@mbadolato mbadolato commented Aug 22, 2013

The directory structure looks fine to me. No immediate concerns come to mind.

One question... I'm fine either way, but is there a particular reason why console should stay in the root and not move to bin/? With the amount of time we fire off the console, it saves a bit of typing to have it in the root (granted), but seeing as it's an executable file, should it be in bin/ with any others that [may] go in there (doctrine, phpunit, etc)?

Also, somewhat on topic and somewhat off topic, a year+ ago, some of us were discussing, on the dev mailing list, the possibility of moving Doctrine entities to a Bundle/Persistence/[Doctrine|Document|Properl|etc] directory structure instead of having each in the Bundle's root directory. That might be a topic for another discussion, while on the subject of reorganization.

@fabpot
Copy link
Member

@fabpot fabpot commented Aug 22, 2013

@mbadolato moving console to bin/ probably makes sense. I would then rename it to bin/symfony.

@fabpot
Copy link
Member

@fabpot fabpot commented Aug 22, 2013

@kimausloos src/ is a well-known convention for storing the code of an app/library.

@everzet
Copy link

@everzet everzet commented Aug 22, 2013

@fabpot I like your directory structure except one bit - src/Resources. Isn't root directory is a root "Resources" folder already? How about this structure instead:

├── bin
│   └─ console
├── composer.json
├── composer.lock
├── phpunit.xml.dist
├── cache
├── logs
├── config
├── views
├── src
│   ├── Acme
│   ├── AppCache.php
│   ├── AppKernel.php
│   ├── SymfonyRequirements.php
│   ├── autoload.php
│   ├── bootstrap.php.cache
│   └── check.php
├── vendor
└── web

?

@webmozart
Copy link
Author

@webmozart webmozart commented Aug 22, 2013

@fabpot ... exactly in this moment I was typing the same thing :) +1

@mbadolato
Copy link
Contributor

@mbadolato mbadolato commented Aug 22, 2013

👍 To @youknowriad's comment about parameters.yml[.dist]. Having that in the root, or closer to it, would be helpful.

@simensen
Copy link
Contributor

@simensen simensen commented Aug 22, 2013

Whatever changes are made along these lines I'd appreciate it if we could keep the use cases of symfony/symfony#6337 in mind.

A summary of that issue is that I'd like to be able to specify the root directory rather than solely relying on the location of AppKernel to define the root directory for me.

Currently the only way to do this is to subclass Kernel and give the constructor a new signature:

<?php

class CustomKernel extends Kernel
{
    public function __construct($environment, $debug, $rootDir = null)
    {
        if (null !== $rootDir) {
            $this->rootDir = $rootDir;
        }

        parent::__construct($environment, $debug);
    }
}

I'm not sure what new magic would be used to determine the "root directory" given this new structure (or what the "root directory" would even mean going forward) but I'm hoping it won't end up making things more complicated or impossible for my edge cases using Kernel outside of Symfony SE contexts.

@matiangul
Copy link

@matiangul matiangul commented Aug 22, 2013

So maybe it could be like @fabpot wrote, but without Resources folder; config and views in src directory ?

@fabpot
Copy link
Member

@fabpot fabpot commented Aug 22, 2013

@mbadolato @youknowriad @everzet I'd like to keep the root directory with not too many files and directories.

As mentioned by @peterjmit, having a src/Resources/ mimics the structure of a bundle, so that is probably more consistent.

@kriswallsmith
Copy link
Contributor

@kriswallsmith kriswallsmith commented Aug 22, 2013

👍 although I would rather see the kernel inside the vendor namespace than in the global namespace.

@lsmith77
Copy link
Contributor

@lsmith77 lsmith77 commented Aug 22, 2013

As for models, this is what the CMF has as its standards: http://symfony.com/doc/master/cmf/contributing/bundles.html#persistence

@webmozart
Copy link
Author

@webmozart webmozart commented Aug 22, 2013

Should check.php go to bin/ too? Maybe together with a rename?

@mykehsd
Copy link

@mykehsd mykehsd commented Aug 22, 2013

+1 for @everzet solution. Putting major application configuration that deep is too cumbersome.

@fabpot
Copy link
Member

@fabpot fabpot commented Aug 22, 2013

@bschussek Indeed, that's a good idea. We would have bin/symfony and bin/check_symfony (or any other better name).

@dcsg
Copy link
Member

@dcsg dcsg commented Aug 22, 2013

👍 for the new directory structure.

@mbadolato moving console to bin/ probably makes sense. I would then rename it to bin/symfony.

👍

@rande
Copy link

@rande rande commented Aug 22, 2013

Why not having all files in one folder (ie /) ? and only used src to hold php class or bundle.

here my proposal

├── cache
├── config
├── composer.json
├── composer.lock
├── AppCache.php
├── AppKernel.php
├── bin
│   ├── console
│   ├── check.php
│   └── SymfonyRequirements.php # maybe this can be merged with check.php
├── logs
├── phpunit.xml.dist
├── bootstrap.php.cache
├── autoload.php
├── src
│   ├── Acme
│   └── Resources
│       └── views
├── vendor
└── web
@peterjmit
Copy link

@peterjmit peterjmit commented Aug 22, 2013

@fabpot @mbadolato @youknowriad @everzet I would also prefer few root files where possible/appropriate. If you are working with other non-php tools (bower, grunt for example) the root folder would get somewhat cluttered.

@gnugat
Copy link

@gnugat gnugat commented Aug 30, 2013

@Seldaek and in the end, you end up having more stuff unignored that ignored stuff.
It's not the end of the world, but it's just not right.

@kor3k
Copy link

@kor3k kor3k commented Aug 30, 2013

@bschussek , @fabpot

For the majority of other cases, one app per project (and thus the content of app/ moved to root) should be fine.

it is common to run multiple virtual hosts on the same server. in that case, multiple apps with different configs but shared code source is the only right way, because having different copies & updates is just a waste of time & space.

Symfony\app\myapp1\
Symfony\app\myapp2\

Symfony\web\myapp1\
Symfony\web\myapp2\

do not remove the app folder but instead move the default app to app/default (and web/default) to suggest that symfony is multi-app capable out-of-the-box.

@stof
Copy link
Member

@stof stof commented Aug 30, 2013

@kor3k Please don't make the directory structure deeper than currently while this discussion tries to simplify it

@evillemez
Copy link

@evillemez evillemez commented Aug 30, 2013

@kor3k That sounds ok in theory, but in practice it seems like it would be a maintenance nightmare, which is why I think it should be discouraged. There's a few problems that come to mind:

  • If you update the core dependencies, how do you know if any of the apps aren't broken? You have to retest all of the apps - assuming you actually have tests.
  • When you deploy in that scenario you have to clear the cache for all the apps.

Maybe that's not a big deal, but it sounds... messy. Composer makes it easy to deal with these issues on an app-by-app basis.

@unhashable
Copy link
Contributor

@unhashable unhashable commented Oct 5, 2013

👍 any chance this will make it in 2.4 next month?

@kor3k
Copy link

@kor3k kor3k commented Oct 7, 2013

@evillemez well, that is both true. but it is both true when you have a single copy for every app as well. the only difference is that in my case, updates are downloaded once.

you say that having multiple apps - one app folder and one web folder per app - is messy. imho much more messy is having app files like "AppKernel.php", "bootstrap.php.cache" etc. and folders like "config", "cache" in the root dir. current behavior is clean and straightforward (all app-related files live inside two folders).

also, this approach will enforce the "one app per one copy" philosophy.

@sstok
Copy link

@sstok sstok commented Oct 7, 2013

@kor3k for whats its worth it, this the multi-app directory structure I came up with.

├── app
│   ├── [Name]
│        ├── autoload.php
│        ├── AppCache.php
│        ├── AppKernel.php
│        ├── config
│        ├── Resources
│             └── views
│        ├── var
│             ├── cache
│             └── logs
│        ├── bin
│             └── console
│        └── web
├── bin
│   └── check_symfony
├── composer.json
├── composer.lock
├── phpunit.xml.dist
├── src
│   ├── Acme
├── var
│   ├── bootstrap.php.cache
└── vendor
@kor3k
Copy link

@kor3k kor3k commented Oct 7, 2013

@sstok yes, that is fine. i would only add a possibility to override location of "bootstrap.php.cache" file and the "web" folder per app, but this suits the needs.

@lemoinem
Copy link

@lemoinem lemoinem commented Oct 7, 2013

Hi there,

I have the feeling this discussion is now missing its target a bit. the original intent of @fabpot was (as stated in #584 (comment) and repeated numerous times afterward) was to simplify the directory structure by removing the possibility of having multiple apps per project with the standard directory structure. This does not implies removing the feature from symfony, but rather making it harder to achieve using the default and standard directory structure. The point behind this choice is also explicitly given in fabpot's original comment.

Bottom line (tl;dr): The point is therefore not to make having multiple apps per projects easier and the directory structure more complex, but the other way around, the directory structure should be made easier to understand and use a priori even if this means sacrificing a straight-forward setup for multiple apps per project setup.

The last proposal toward this goal is (as far as I can judge): #584 (comment) It also includes a motivation for each proposed change and has received numerous 👍.

@yellow1912
Copy link

@yellow1912 yellow1912 commented Oct 10, 2013

I'm working on a project with SF2 where we find the ability of having multiple app per project very helpful.

The project is a hosted website service where our customers can create their own websites all run on our core code. Instead of having to copy hundred of MBs of files to each site, we simply create a new app folder for each site which will the share the same vendor codes. This way, each site can have its own configuration, logs etc while using the same core code base and thus make deployment, upgrade and such much much easier for us (and also save us tons of money on hosting space as well)

So I think multi-app per project does have its own application, and as more and more people are looking at building applications on the cloud and distribute them as service to each customer I think the ability to have multiple apps per project is becoming more relevant.

@stof
Copy link
Member

@stof stof commented Oct 10, 2013

@yellow1912 Please read the discussion above. This change would not remove the possibility to define multiple apps in a project. It would only remove this constraint from the default project structure (which has been defined to support this at first). People using multiple apps in the same project should be able to change the project structure to separate apps.

@patie
Copy link

@patie patie commented Nov 6, 2013

We are also using multiple apps on one software. Please dont complicate possibility to create multiple apps in one symfony installation out-of-the-box.

@rk3rn3r
Copy link

@rk3rn3r rk3rn3r commented Dec 9, 2013

Hello everyone again.

I already took part in this discussion from the start.
Today I want to bring up some new requirements we have now and we didn't had it in the past.

Our application is very big. We have a very performance oriented main / 1st level application that makes much money every year. For this application everything should be very performance oriented (low memory footprint, fast code).
Then we have some so called "2nd level applications", in most cases backend apps to view, manage or edit the data shown on the frontend app. These apps does not have these performance pressure, but things like the community or B2B platforms should also care and, because most of dev ressources are there for the main app, the backend app, where ever possible, should reuse services and code by the main app. just for organizing a lean and synergetic development of the 2nd level apps.
This was our former status.

Since some time now, we have two new locations where we are doing development. The applications developed there were totally seperated from our core, till now. But now parts like some of the 2nd level applications are moved to these locations. And we don't want to loose synergetic effects and the opportunity to deploy these applications altogether as a big app and later also separately.

So these apps should always share code for don't have so much duplicated code, but there is also the need, that a grow of one application should NOT make the other apps, especially main app, bigger.

To make the issue completed, there are different repositories to develop the different parts of the application. There is a Core/API repository, there is one repository for every 2nd level app and another for the 1st level app, to spread development over the locations.

Best regards,
René

@cordoval
Copy link
Contributor

@cordoval cordoval commented Mar 13, 2014

👍 i wonder when someone will send a PR of a cookbook with multiple ways of doing multiple apps into one install and also cookbook explaining reformatting the folder structure easily to adapt custom needs. SE can be left out as it is if no major changes are required but if it has to change, then i am 👍 too to show an example on how it can be reconfigured.

@wouterj
Copy link
Member

@wouterj wouterj commented Mar 13, 2014

also cookbook explaining reformatting the folder structure easily to adapt custom needs

http://symfony.com/doc/current/cookbook/configuration/override_dir_structure.html (I admit, the app dir is missing)

fabpot pushed a commit to sensiolabs/SensioDistributionBundle that referenced this issue May 9, 2014
This PR was squashed before being merged into the 3.0.x-dev branch (closes #118).

Discussion
----------

Add new directory structure handler

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Fixed tickets | #117
| License       | MIT

This is a first move toward symfony/symfony-standard#584
This allows the use of the new directory structure (not by default).

Commits
-------

da0eea9 Add new directory structure handler
fabpot pushed a commit that referenced this issue May 9, 2014
This PR was squashed before being merged into the 2.4-dev branch (closes #641).

Discussion
----------

Add new directory structure hook

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Fixed tickets | #584
| License       | MIT

This requires sensiolabs/SensioDistributionBundle#118 to be merged

Commits
-------

bffde32 Add new directory structure hook
@fabpot fabpot closed this May 9, 2014
@weaverryan weaverryan mentioned this issue May 3, 2015
0 of 7 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.