Move contents of app/ to / #584

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

Projects

None yet
@webmozart
Member

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.

Member
Tobion commented Aug 19, 2013

Duplicate of #501 and #325

Member
lyrixx commented Aug 19, 2013

I'm totally +1 with this ;)

Owner
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).

Member

@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.

Owner
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

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

iansltx commented Aug 22, 2013

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

Contributor

@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
ghost commented Aug 22, 2013

I like that. It just makes more sense.

tipyy commented Aug 22, 2013

+1

Contributor

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.

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

Contributor

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

Contributor

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.

Owner
fabpot commented Aug 22, 2013

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

Owner
fabpot commented Aug 22, 2013

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

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

?

Member

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

Contributor

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

Contributor

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.

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

Owner
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.

Contributor

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

Contributor

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

Member

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

mykehsd commented Aug 22, 2013

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

Owner
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 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 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

@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.

Owner
fabpot commented Aug 22, 2013
├── bin
│  ├── symfony
│  ├── check_symfony
├── cache
├── composer.json
├── composer.lock
├── logs
├── phpunit.xml.dist
├── src
│   ├── Acme
│   ├── AppCache.php
│   ├── AppKernel.php
│   ├── Resources
│       ├── config
│       └── views
│   ├── SymfonyRequirements.php
│   ├── autoload.php
│   ├── bootstrap.php.cache
├── vendor
└── web
Contributor
hhamon commented Aug 22, 2013

Keeping few files and directories at the root is better to me. Otherwise I fear it will look like symfony 1's directory structure with lots of directories at the root. Beginers with symfony 1 were a bit confused with so much directories at the root.

hussani commented Aug 22, 2013

@fabpot +1 for this structure.
Does bin/check_symfony and SymfonyRequirements.php can be merged?

Owner
fabpot commented Aug 22, 2013

@hussani No, they cannot and SymfonyRequirements.php is also used by web/config.php.

rande commented Aug 22, 2013

I don't get why configuration files should be in the src folder ? it is not code, the config folder can be valid to also contains others configurations files which are not related to Symfony.

Owner
fabpot commented Aug 22, 2013

@hhamon I agree with you, but the current structure seems even more confusing.

Contributor

@rande i had the same feeling at first .. then again Bundle configuration is in there already. so the only config file that to me feels "special" is indeed the parameters.yml as others have noted.

Owner
fabpot commented Aug 22, 2013

@rande The config can be in plain PHP. That said, I put it under Resources/ which is a Symfony convention to store non-code files.

I don't like the idea of src/Resources or any other generic PHP files (other than autoloader code) living in the src dir. Everything in src should be namespaced to follow PSR-0 that everyone is familiar with now. \AppKernel and SymfonyRequirements can live there because they're in the global namespace.

If Resources lives in src I imagine having to tell developers new to Symfony "Here are the PSR-0 namespaced classes you're accustomed to. Well except this Resources directory which doesn't follow this convention at all... and by the way it's only special to Symfony"

Owner
fabpot commented Aug 22, 2013

@lsmith77 We could move the parameters.yml file to the root directory.

Contributor

@hhamon I also agree that we should not go too crazy with moving things to root. Ideally there should be no more than 10-15 files+dirs in the root.

Contributor
hhamon commented Aug 22, 2013

@fabpot your last directory structure proposal sounds good to me. I'm wondering if we could combine /cache and /logs directories in something like a /tmp directory.

Contributor

+1 for @everzet's solution, just because the config file is deeper than currently in @fabpot's proposal (app/config => src/Resources/config). Adding one click to a very common action (adding an element in the configuration) is not a simplification.

Owner
fabpot commented Aug 22, 2013

@johnkary that's already the case for Bundles.

Member

@johnkary src/Resources makes a lot of sense once we start doing things like this

@hhamon combining cache and logs into /tmp sound good as that leaves option for more stuff like /sessions

rande commented Aug 22, 2013

Cannot we have a CoreBundle used to initialized the application ? So this bundle can hold the resources and configuration folder ? so the src folder will not mixed up

Owner
fabpot commented Aug 22, 2013

@Future500 @hhamon I'm not too comfortable naming a directory tmp/, but I cannot explain why. That's just a feeling I have.

Contributor

@hhamon the sf1 dir file structure, which is similar to Rails dir file structure, was quite easy to understand for the beginners I spoke to. Much easier to understand than the sf2 file structure.

Contributor
hhamon commented Aug 22, 2013

@fzaninotto really? When training peope I had lots of remarks by trainees wondering why there were so many files when bootstrapping a new project. I really think Symfony2's directory structure is easier to work with.

dcsg commented Aug 22, 2013

@hhamon combining cache and logs into /tmp sound good as that leaves option for more stuff like /sessions

👍

Member

I tend to agree with @rande and @kriswallsmith that AppKernel.php, AppCache.php and Resources/ should be added to a vendor-namespaced bundle that is generated when the application is created. Then the bundle is the same as any other bundle, except that it contains a kernel.

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

Beginners then really only need to care about the src/Me/MyAppBundle directory, which simplifies things a lot.

Contributor

It might be sensible to have a look at the structure KnpLabs originally proposed for their RadBundle .. not sure if this is still documented somewhere. In the original version they heavily modified the dir structure.

Owner
fabpot commented Aug 22, 2013

@bschussek This directory structure has several problems:

  • The kernel/cache/config files are not generated, so adjusting the vendor name means a tedious work that needs to be done by the developer
  • The configuration is buried in a very deep directory tree, and that's something we want to avoid (as mentioned by many others in this thread)
  • The Resources/ directory is a "global/fallback" one. As the namespace would be dynamic, I'm not sure how it would work.
rande commented Aug 22, 2013

@bschussek you are too quicker with your ASCII art folder ;) I do have a small modification, there is no files anymore in the src folder, all files are moved to the Kernel|Core|Whatever bundle.

├── cache
├── config
├── composer.json
├── composer.lock
├── bin
│   ├── console
│   ├── check.php
│   └── SymfonyRequirements.php # maybe this can be merged with check.php
├── logs
├── phpunit.xml.dist
├── src
│   ├── Symfony\CoreBundle
│   │   ├── Resources
│   │   |       ├─── views
│   │   │       └─── config
│   │   ├─- AppCache.php
│   │   ├─- AppKernel.php
│   │   ├─- autoload.php
│   │   └── bootstrap.php.cache
│   ├── Acme
├── vendor
└── web
pgodel commented Aug 22, 2013

Instead of tmp/ it could be named var/

rande commented Aug 22, 2013

good luck @fabpot ;) you have some ideaS now.

tseho commented Aug 22, 2013

@rande Cannot we have a CoreBundle used to initialized the application ? So this bundle can hold the resources and configuration folder ? so the src folder will not mixed up

👍

Owner
fabpot commented Aug 22, 2013

Moved logs and cache to a new var directory

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

The var/ directory can host other directories like a sessions/ one or a build/ one.
The bin/ directory is the default one used by Composer for binaries, CLI tools, so that's consistent.

dcsg commented Aug 22, 2013

👍 to the @rande idea of having a CoreBundle

@fabpot looks good because under var we can have build api and so on from phpunit, phpdoc as example

👍 @rande for directory structure

Contributor
hhamon commented Aug 22, 2013

@pgodel /var is great!

+1 for /var

👍 for /var too

👍 for /var as well.

Contributor

This chat goes in all directions and I wish @fabpot good luck to make a good choice.

But in my opinion, instead of discussing the directory structure (i.e. the solution), we should first agree on the objectives of a good file structure (i.e. the problem). Which development use cases should be addressed first? Which ones are not common, and therefore may suffer more clicks through directories? Why should files be grouped together?

I don't even see a consensus on the problem, I don't see how we can all agree on a directory structure...

gyndav commented Aug 22, 2013

+1 for @everzet directory structure

ratibus commented Aug 22, 2013

Why bootstrap.php.cache isn't in the cache directory ?

👍 to /var...somewhat sysadmin friendly!

Owner
fabpot commented Aug 22, 2013

@fzaninotto I agree.

My objectives:

  • not too many directories/files under the root directory
  • easy to understand directory/file names (using well-known names like src/, var/, or bin/)
  • easy to find files based on their type (a PHP file should be in src/ for instance)
  • avoid a too deep directory structure for everything that needs to be edited by the developers on a regular basis (and an even less deep directory structure for ops guys)
  • keep the directory structure easily manageable by Symfony (fixed names for the Kernel, ...)
  • keep the current features easily implementable ("global" resources in the Resources/ directory for instance)
  • stick with the conventions we already have in Symfony (like the bundle dir structure)
  • avoid names with a common prefix in the same directory (console vs composer.json for instance at the root)
     * keep the possibility to have more than one application in a project

Any other ones?

rdohms commented Aug 22, 2013

IMHO this latest proposal makes the src folder pretty polluted.

+1 for /var - a specific folder for devops to watch out for during deployments!

dcsg commented Aug 22, 2013

@rdohms agree with you, IMO the @rande solution should solve it.

tseho commented Aug 22, 2013

@fzaninotto A new directory structure could fix the fact that our application code is currently divided between two folders (app and src) with no real benefit.

Owner
fabpot commented Aug 22, 2013

@tseho the benefit is clear when you have more than one app in a project. And this thread started because this is not a very often used feature.

to seperate config in app and source in src is better for capifony i think
because they are shared files

Contributor

@fabpot for your first objective, I'd temper it by saying "No more than 4 directories in the root directory where the developer should have to go on a regular basis". This excludes var/tmp, and vendor.

This is what makes me think that we can add a config directory to bin, src, and web - fits the requirement.

Owner
fabpot commented Aug 22, 2013

@danielcsgomes @StefTweet I don't see how @rande proposal would be implementable without breaking a lot of stuff internally (I'm not even sure that this would be possible). That's also something to keep in mind.

rande commented Aug 22, 2013

So following @fabpot's requirements:

├── composer.json
├── composer.lock
├── bin
│   ├── console
│   ├── symfony_check
├── resources
│   ├── views
│   └── config
├── var
│   ├── cache
│   ├── sessions
│   └── logs
├── phpunit.xml.dist
├── src
│   ├── Acme
│   ├── AppCache.php
│   ├── AppKernel.php
│   ├── autoload.php
│   ├── SymfonyRequirements.php
│   ├── bootstrap.php.cache
│   └── Acme
├── vendor
└── web
Contributor
mykiwi commented Aug 22, 2013

@rande 👍

Owner
fabpot commented Aug 22, 2013

Moving the config dir to root:

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

Having the config/ dir under the root dir slightly breaks the Resources structure we have in bundle, but I can live with that as it makes the configuration easily accessible.
The var/ directory can host other directories like a sessions/ one or a build/ one.
The bin/ directory is the default one used by Composer for binaries, CLI tools, so that's consistent.

dcsg commented Aug 22, 2013

@rande 👍

Owner
fabpot commented Aug 22, 2013

Moving the views dir to root would probably "solve" the clutter in the src/ directory (not sure if it won't be difficult to implement, without big BC breaks, though):

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

Having the config/ dir under the root dir slightly breaks the Resources structure we have in bundle, but I can live with that as it makes the configuration easily accessible.
The var/ directory can host other directories like a sessions/ one or a build/ one.
The bin/ directory is the default one used by Composer for binaries, CLI tools, so that's consistent.

gnugat commented Aug 22, 2013

I'd 👍 for renaming app/console to bin/symfony, and I propose to rename app/check.php to bin/check_requirements.php.

Moving together cache and logs in var is a great idea: now rights can be applied on a unique directory (recursively).

If src/Resources is only ever likely to contain views/, then it seems like moving both src/Resources/config/ and src/Resources/views/ to a top-level resources/ makes sense, and it keeps things compact.

I agree with @rdohms about /src getting cluttered, and I definitely like having /config and /views at the root level (in fact, /views at the root is how I often configure Silex apps). And the /var idea is excellent.

I do have a scenario where I could (and probably should) use the multiple-apps-in-a-project functionality, but the architecture of that project actually ended up splitting it into two codebases that just inherit common bundles. So it's probably the case that even when it would be a good idea to put multiple apps inside the same project, people still aren't doing it - making this discussion an excellent one to have.

Owner
fabpot commented Aug 22, 2013

@rande @evillemez The resources directory under the root dir would be named Resources/. But at this point, I don't see why we would keep the resources/ directory.

dcsg commented Aug 22, 2013

@fabpot 👍 for cleaning src folder. Maybe two more directories on the root would be unnecessary. I would prefer a resource directory on the root since I could add other stuff to it.

@fabpot The resources directory in root leaves room for.. other stuff. Plus reduces the count in / by one already :)

Owner
fabpot commented Aug 22, 2013

@danielcsgomes @rande @Future500 So, instead of resources, we could have a etc/ directory?

Contributor
mykiwi commented Aug 22, 2013

@fabpot 👍 etc/

├── bin
│  ├── symfony
│  ├── check_symfony
│  └── SymfonyRequirements.php # maybe this can be merged with check.php
├── composer.json
├── composer.lock
├── phpunit.xml.dist
├── app
│   ├── AppCache.php
│   ├── AppKernel.php
│   ├── config
│   ├── Resources
│   │   ├── java
│   │   └── views
│   ├── autoload.php
│   └── bootstrap.php.cache
├── src
│   └── Acme
├── var
│   ├── builds
│   ├── api
│   ├── cache
│   └── logs
├── vendor
└── web

Question: Why is Ressources with uppercase and config with lowercase?

@boonkerz Because that's how it is inside the bundles. /app/Resources is supposed to be a sort of "root bundle" for an application.

Owner
fabpot commented Aug 22, 2013

Adding an etc/ directory

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

The etc/ directory is about the configuration (the developers can add other stuff there too).
The var/ directory can host other directories like a sessions/ one or a build/ one.
The bin/ directory is the default one used by Composer for binaries, CLI tools, so that's consistent.

dcsg commented Aug 22, 2013

@fabpot 👍

Owner
fabpot commented Aug 22, 2013

hehe, looks like we are slowly moving towards a Unix-like directory structure

@fabpot +1 I like that a lot, it feels right.

/etc doesn't really convey any meaning... /resources seems more fitting to me.
Then again, /etc does match more with file-system conventions.

@fabpot @skoop @Seldaek About cache and logs directories, default could be var/cache/app/ / var/logs/app/. This makes it still possible and clean the way to do multi-apps projects (makes sense in eZ Publish).

So if you want to have app2 in your project, you would have var/cache/app2 and var/logs/app2.

Contributor

👍

The changes sound reasonable to me. Will you make this change with a 2.x release or is this rather a plan for a 3.0?

There is no explaination about the "src" folder.
If the "src" folder is only created for the app, why can it be moved inside the app folder ?

├── app
│ ├── autoload.php
│ ├── AppCache.php
│ ├── AppKernel.php
│ ├── config
│ └── Resources
│ └── Acme

rdohms commented Aug 23, 2013

@JLepeltier because its a standard practice in most PHP projects.

Member

I think check_requirements should be integrated into bin/console/bin/symfony and executed when only one argument --check is provided

bin/console --check
Owner
fabpot commented Aug 23, 2013

@bschussek that's not possible as the check script checks that Symfony can run (including bin/console ;)).

Member

I agree that the proposed directory structure is better ... but is it really needed?

Remember the article that @fabpot published a few months ago:

[...] in the coming months, the Symfony core contributors should focus their efforts toward stabilizing the existing features instead of working on new ones. At this point, backward compatibility and stability are more important than everything else.

This change is pretty BC-friendly to the code, but breaks (almost) all of the Symfony documentation, tutorials, blog posts, certification, training materials, etc. It also changes some well known conventions as php app/console and phpunit -c app. Lastly, it could also break the tools and processes built by DevOps teams.

XWB commented Aug 23, 2013

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.

I guess we're just one of those few people using multiple applications in 1 project. Our app directory looks like this:

|---- app
  |---- Website1
    |---- cache
    |---- config
    |---- logs
    |---- Resources
  |---- Website2
    |---- cache
    |---- config
    |---- logs
    |---- Resources
  |---- Website3
    |---- cache
    |---- config
    |---- logs
    |---- Resources
Contributor

Maybe a bit of topic: @Seldaek about the console / symfony discussion: What if Composer would introduce a map of command name to local file name, like the "bin" option in NPM? This way developers can choose themselves whether it's bin/console or bin/symfony ;)

Owner
fabpot commented Aug 23, 2013

@javiereguiluz I've never said that this directory structure would land in the 2.x branch. In fact, it cannot be done before 3.x. That said, if people want to opt in for the new directory structure in 2.x, they can do it right now. We could even think of proposing this alternative layout as an optional step (haven't really thought about the details yet, but that should be possible).

Member

@fabpot Sure, we need to short-circuit Symfony in this case. But for the end-user this detail shouldn't matter.

if (2 === $_SERVER['argc'] && '--check' === trim($_SERVER['argv'][1])) {
    // check_requirements
}
// console
Owner
fabpot commented Aug 23, 2013

@javiereguiluz @derrabus I've updated my proposal with a new paragraph about when these changes would occur to make things clearer.

Owner
fabpot commented Aug 23, 2013

@bschussek That won't work as there are some use statements in the console script. The check script should work even on PHP 5.2. And one best practice is to actually remove this check script as soon as you ran it.

Contributor

@fabpot Thanks. :-)

Koc commented Aug 23, 2013

how to handle multiple kernels applications with new structure?

Member
Tobion commented Aug 23, 2013

@fabpot I just thought that it's really possible to combine SymfonyRequirements.php and check.php into bin/symfony_requirements.php and still have it includable as lib for web/config.php. I'll open a PR.
Then we don't have the problem where to place SymfonyRequirements.php anymore.

TomiS commented Aug 23, 2013

Why not bin/Command instead of bin/console to be consistent with naming of bundle console commands?

Contributor
1ed commented Aug 23, 2013

OFF: I think it would be great if composer could check generally if an environment (php configuration, etc...) meets the requirements of a package. It is a common task and should be addressed at community level. But it's an another topic.

If the proposed changes won't be a reality until symfony 3.0 (and you said 3.0 wasn't coming anytime soon) why bother with this discussion at this time?

As @javiereguiluz mentioned (and as you did when you said Twig wasn't getting namespaces) a little bit of stability won't hurt. Maybe it's not the best of the best of the directory sctructures, but it's not bad and I don't see any particular benefit of changing it. It's not that terrible to type phpunit -c app/

imho console must stay in app folder because it's code may be changed by developer
bin directory contains autoinstalled files via composer and must be added to ignored pathes in vcs

gnugat commented Aug 23, 2013

@Partugal I'd rather say that bin directory contains your own scripts (like install.sh, test.sh, etc), and shouldn't be ignored by VCS. I really think it's an error to put autoinstalled files via composer in it (they should be put in the standard vendor/bin.

gjuric commented Aug 23, 2013

+1 for changing composer.json to put vendor binaries into vendor/bin. This will solve the problem of possible collisions with the vendor provided bin files.

What about moving the src folder into app folder?

├── app
│   ├── config
│   ├── Resources
│   │   ├── translations
│   │   └── views
│   ├── src
│   │   └── Acme
│   ├── autoload.php
│   ├── AppCache.php
│   └── AppKernel.php
├── bin
│   ├── console
│   └── symfony_requirements
├── var
│   ├── cache
│   ├── logs
│   ├── bootstrap.php.cache
│   └── SymfonyRequirements.php
├── composer.json
├── composer.lock
└── phpunit.xml.dist

src is part of the application, and it makes navigating code in IDEs easier. If you look at the app folder as an applications root folder, then config, resources and src are in the "root" folder.

@Koc you can still create multi-app websites, and have as many AppKernel directories as you wish to.
Exactly the same way as you already do right now, you simply need to point your front controllers to the correct AppKernel, and override the default directories in your AppKernel.

Exactly the same way as you would already have done before.

everzet commented Aug 23, 2013

Please do not put src/ into app/. Separation of symfony and non-symfony assets should be preserved. app/ is a Symfony2-centric directory with sf2-related configs and classes. src/ is a set of my own custom classes, most of which could live without Symfony2 and thus should not be locked to framework directory structure.

everzet commented Aug 23, 2013

... moving custom bundles into app/ could make sense though:

├── app
│   ├── config
│   ├── Resources
│   │   ├── translations
│   │   └── views
│   ├── bundles
│   │   ├── AcmeCalculatorBundle
│   │   ├── AcmeNavigatorBundle
│   │   └── AcmeProductBundle
│   ├── autoload.php
│   ├── AppCache.php
│   └── AppKernel.php
├── bin
│   ├── console
│   └── symfony_requirements
├── src
│   ├── Entity
│   ├── Navigator
│   └── PriceCalculator
├── var
│   ├── cache
│   ├── logs
│   ├── bootstrap.php.cache
│   └── SymfonyRequirements.php
├── composer.json
├── composer.lock
└── phpunit.xml.dist

Thus, everything framework-specific lives in app/ and all domain-related code lives in src/.

👍 bin/console

$ sudo ln -s path/to/bin/console /usr/bin/symfony

@everzet If you wish to separate your business logic from your bundles, you may already do so using satis and composer. And very few people they can (and should) actually know that bundles are only related to integrating business logic to symfony.

everzet commented Aug 23, 2013

@csarrazi thanks for information, but my app bundles are still part of my project. They are simply not part of my domain-related code. It's stupid to move non-reusable project-specific bundles outside of the project just to separate them from domain logic.

And very few people they can (and should) actually know that bundles are only related to integrating business logic to symfony.

Those are the same people that want to move entire src/ folder into app/. Thus, I'm totally Ok if they'll continue to wrap everything in bundles inside app/bundles folder. But I think we should be clear that project source code (src/) IS NOT part of the Symfony2 app (app/), it's in best case opposite.

gjuric commented Aug 23, 2013

I agree with everzet, but is this going to make autoloading a little bit harder?

If bin/console vs bin/symfony is still a debate, why not bin/app ? It's an entry point into the app, the same as a web/app.php, just from a different environment, and because it's in bin/ it's clearly a CLI tool. If not, may as well stick with bin/console, everyone is used to it.

asm89 commented Aug 23, 2013

If you look at multiple kernels setups such as the one @XWB showed above, moving "custom" bundles into app/ would be rather annoying.

Is it really relevant what is the name of symfony cli tool ? Everybody can name it as he/she want. It is not so important for app

@Tobion Tobion referenced this issue in sensiolabs/SensioDistributionBundle Aug 23, 2013
Open

[RFC] make requirement-check a bin resource #97

2 of 8 tasks complete
o commented Aug 23, 2013

👍 for @fabpot s proposal, it looks good.

@ghost
ghost commented Aug 25, 2013

Latest fabpot proposal looks fine to me (#584 (comment))

  • love the idea of "var" directory,
  • "bin" seems natural place for console
  • "src" untouched - also great
  • "app" without console, logs and cache directories looks neat at last

Sure glad this is targeting S3 not S2.

Maybe it's just me but I always cd to the app directory before running tests or console commands. Never seemed to have a problem and it seems to solve the problem addressed by this gist.

When first moving to S2.0 I did make myself an apps directory and then had multiple apps under it. Just had to tweak a couple of paths. Also had sub directories under web.

Stopped doing this once composer came along.

This proposal is fine. Although I think there's no major issue with breaking compatibility if the target is version 3.0.
In order to have more in common with other frameworks (I'm not speaking only about PHP there), It would actually make sense to move the config folder outside of app, and include autoload.php inside it.

Something like

├── app
│   ├── AppCache.php
│   ├── AppKernel.php
│   └── Resources
│       └── views
├── bin
│   ├── console
│   └── symfony_requirements
├── config
│   ├── autoload.php
│   ├── config.yml
│   ├── config_dev.yml
│   ├── config_prod.yml
│   ├── config_test.yml
│   ├── parameters.yml.dist
│   ├── routing.yml
│   ├── routing_dev.yml
│   └── security.yml 
├── composer.json
├── composer.lock
├── phpunit.xml.dist
├── src
│   └── Acme
├── var
│   ├── bootstrap.php.cache
│   ├── cache
│   ├── logs
│   └── SymfonyRequirements.php
├── vendor
└── web
rk3rn3r commented Aug 25, 2013

@fabpot We are also using multiple apps on one software stack. For this we are using one AppKernelAbstract that configures some directories like cache. For our live servers for example it is moved to one special folder where the webserver has write rights.
Then for every application we have one AppKernel that extends the global AppKernelAbstract.
For this we also make heavy usage of environments config_{ENV}.xml in the app/config folder.
We need for example environments for dev, live, integration, local staging, some live-staging and jenkins etc.

Also we should keep in mind that the configuration placed in app/config id loaded at last (after registerBundles) and so it is also a feature that configuration stored here is always the leading one.

So for us it makes sense to keep these features and keeping the app-folder.

What we give +1 for would be removing the Resource folder from app because global views never make sense.
And if this really needed it is possible to do it by a GlobalLayoutBundle that can provide global views (and configuration that can overwritten/changed). A /config folder in root would then be the replacement for config folder in app. Probably /app then could be renamed to /kernel.

Best regards,
René

@ghost
ghost commented Aug 26, 2013

What we give +1 for would be removing the Resource folder from app because global views never make sense.
And if this really needed it is possible to do it by a GlobalLayoutBundle that can provide global views (and configuration that can overwritten/changed). A /config folder in root would then be the replacement for config folder in app. Probably /app then could be renamed to /kernel.

We also use a bundle for customisation,

hacfi commented Aug 26, 2013

Talking about restructuring things I’d like to see a more structured config directory like https://github.com/havvg/symfony-sandbox/tree/master/app/config . Of course you can always change this yourself but right now it’s some overhead (see https://github.com/havvg/HavvgDRYBundle/blob/master/Kernel/ContainerConfigurationRegistry.php) or you have to add all those files as imports. The main advantage is that you can just download a bundle’s yml config and copy it in the config/bundles directory without having to edit the config.yml manually.

/cc @havvg

rk3rn3r commented Aug 26, 2013

Hello @hacfi , I think this is already possible and the organization of the config-files is up to the developer and there is no restriction on that. there is currently only one structure defined by the basic AppKernel,that is config.xml/yml etc and config_{ENVIRONMENT}.xml/yml etc. should come from app/config/, all other things are only imports in these files and also this loading can be customized by implementing your own AppKernel.

also copying is not a good solution as currently it is a very good feature that the order of the calls of the loaded Bundles in registerBundles in the AppKernel defines which bundle is able to overwrite the configuration of another bundle when it is loaded/registered after the one that should be overwritten. So in this case implicit is better then explicit (how it is in many cases).

The new dir struct is awesome!:)
Please rename var/logs to var/log just for the consistency's sake (like /config, /vendor)

hacfi commented Aug 26, 2013

@brav0 I know but if you have a look at https://github.com/havvg/HavvgDRYBundle/blob/master/Kernel/ContainerConfigurationRegistry.php you see that it’s some overhead. Especially for bundle configs I think it would be very helpful to include all files from a specific directory.

skler commented Aug 27, 2013

In my opinion even more projects were developed with Symfony even more difficult the updates maintenance is. So in real life could be better group shared files together and suggest the use of different app folder for every project as best practices. Moreover every app folder should be consistent. Creating new project should require only a copy. This solution is focused to an enterprise usage, maybe it isn't the friendly one.

This is my proposal:

.
├── app                   # an app folder could be easily renamed without code modifications
│   ├── AppCache.php
│   ├── AppKernel.php
│   ├── autoload.php
│   ├── bin               # binaries are stictly connected with kernel
│   │   ├── check
│   │   └── console
│   ├── etc               # app config
│   │   ├── config
│   │   ├── deploy
│   │   └── routing
│   ├── src               # old "Resources" folder named as src for specific app overwrite 
│   │   └── TwigBundle    # example: twig bundle exception views 
│   ├── tmp               # could be removed without loosing sensible data
│   │   ├── cache
│   │   └── session
│   ├── var               # could contain migrations and backups
│   │   └── log
│   └── web
├── composer.json
├── composer.lock
├── lib                   # shared libs (old vendor)
├── phpunit.xml.dist
└── bundle                # private bundles
    └── Acme
        ├── MyFirstBundle
        └── MySecondBundle

In composer can we respect the following for the bin directory:

    "config": {
        "bin-dir": "bin"
    },

And why no group AppCache.php, AppKernel.php,autoload.php inside a sys folder ?

What is the advantage / disadvantage ?

I think the @fabpot propose

├── bin
      ├── symfony
      ├── check_symfony
├── composer.json
├── composer.lock
├── etc
      ├── config
└── views
      ├── phpunit.xml.dist
├── src
      ├── Acme
      ├── AppCache.php
      ├── AppKernel.php
      ├── SymfonyRequirements.php
      ├── autoload.php
      ├── bootstrap.php.cache
├── var
      ├── cache
      ├── logs
├── vendor
└── web

Would be wonderful

The proposal of @skler have more sense (in my opinion). The structure is cleaner, it's based on linux and probably more understandable in it's logic. She is may not perfect but I think that is closest to the goal with a clean restructuring and improved. Now if @fabpot can explain why he go on this way (for her structure), may be we can understand what can be good or not with his goal.

EDIT: nvm i didn't see #584 where @fabpot explain why.

+1 for @fabpot ’s latest proposal.

  • app and src should stay separated, src should stay only bundles.
  • A bin is needed as other libs like to declare scripts, they should all be at the root
  • A var folder is needed. This folder would contain everything that can be modified by the system. This could mean this folder could be symlink to a writable partition while the rest is readonly.
  • I would have liked an etc directory, but having AppKernel, config and Resources together seems logical.

However, we need uploads directories, one public and one private. The public needs to be accessible, so it should be in the web folder. The private one could be in var. If the filesystem supports symlinks, web/uploads could be a symlink to var/uploads/public.

+1 for the system private uploads and public uploads

frastel commented Aug 28, 2013

Not every project implemented with Symfony2 uses uploads. So why should the framework concern with these custom requirements? It is completely up to the developer to build a good structure for the project's uploads.

Contributor

Frank is right. On a framework level we cannot make decisions what a good
uploading strategy for the users special usecase is.

On Wed, Aug 28, 2013 at 6:04 PM, Frank Stelzer notifications@github.comwrote:

Not every project implemented with Symfony2 uses uploads. So why should
the framework concern with these custom requirements? It is completely up
to the developer to build a good structure for the project's uploads.


Reply to this email directly or view it on GitHubhttps://github.com/symfony/symfony-standard/issues/584#issuecomment-23426512
.

Member
stof commented Aug 28, 2013

Thus, uploads are not always on the filesystem of your app. As soon as you add a second server with a load balancer, such setup fail (or requires synchronizing uploads between both servers).
My app is putting uploads in a S3 for instance.

I agree with all of you, but it is a lot like sessions, it may be stored in the system’s temp dir, it may be stored in app/cache or whatever, it is a configuration.

I would see an Uploader service with uses by default a FilesystemStorage, overridable. Imagine configuring this, having dev settings, etc.

Perhaps this already exists, but having core interfaces with a default implementation would standardize things a lot.

When we use multiple apps in the same directory, then the /web must in the app directory
because we should not merge css,js in one directory for different apps or?

rk3rn3r commented Aug 28, 2013

@lavoiesl you mean CoC? Convention over Configuration, but often "explicit is better then implicit".

to summarize: the new directory structure should handle also temp files, to discuss more about that here is a little off-topic, isn't it?

as I already said, I would prefer the current structure, optimizing on some parts could be a good idea though.

additionally I want to put in some suggestions and ideas, correct me when I'm wrong:

for example, one good thing is, that parts of the application are together in /app (or how this dir will be called in the future). for example the AppKernel(s) are in that directory. and what uses the AppKernel/s? right, the console! so it make sense to have it near to the AppKernel(s) placed as you would in general need one console for each AppKernel.
also storing the environment-configs, eg config_dev.xml, that are loaded by the AppKernels near them is not a bad practice. For me, having things that relate each other grouped on directory basis makes a high visibility.

When you are programming a big platform and/or in big teams visibility is very important, and directories should be structured logically that they group things that relate each other together.
and when we are thinking about a new root directory structure it would be very important, that every directory is directly trivial to every programmer, what he will find in it.

having this in mind we should talk about, if having a global configuration like we have now in /app/config/ is the right pattern to keep.
for example: we are working on a very big platform with many developers and because it is so easy to add your new service-configuration to /app/config/ many devs put their configuration there. but often this is the wrong place as this global configuration can not be overwritten as the default AppKernel loads this config at the end (so it overwrites all other definitions).
And this behaviour could easily be replicated by creating a /src/Acme/Bundle/GlobalConfigurationBundle that holds only these global configuration parts and having an AppKernel, that always loads this bundle in the end of the AppKernel::registerBundles run.

so also with this in mind, for me it is not a good idea to store AppKernels in the root, as (think of a bigger team) only a few programmers have to know and take care of AppKernels, when you move them to root, it makes them very important. but when you created one AppKernel that fit your needs there are not many reasons to change it later so it should go a directory like /app (or however you want to name it) [yes, "only two hard things in computer science: cache invalidation and naming things" -- Phil Karlton]

what else relates to the AppKernels? the HTTP-endpoints (*.php) in the DocRoot /web folder. but storing the Kernels there is a) not a good idea and b) a bad idea because in general this could be a public accessible folder.

also having global views, like in /app/Resources/views/ makes no sense to me. (explanation in one of my other posts here, and can also be implemented in a GlobalFrontendBundle similar to the GlobalConfigurationBundle).

autoloading config files: not a good idea because sometimes ORDER matters and "explicit is better then implicit" again and especially for configuration. configuration should be well-defined and terminated.

moving /app/cache/ to root: also the question: is a bigger visibility needed of cache? no, so the idea of putting it in a directory like /var/cache/ or /data/cache/ or something, is a good idea. but it's the same like we have now, only /var is called /app.

that's enough for now.

best regards and a great discussion here!

rk3rn3r commented Aug 28, 2013

@boonkerz this is not related to directory structure but to deployment of your platform.
on dumping your assets you could always specify your target path, and as long as you need a different AppKernel for a special application, you also need a special console and so you can generate your assets to a special directory for your application, or you have to keep
any eye on the names of your generated asset files, so you never have the same name twice (if you generate them in the same directory).

@stof This project looks awesome, thanks for that. Perhaps a small part of KnpGaufretteBundle could make it to Symfony or at least declare some interface that KnpGaufretteBundle could implement and AsseticBundle could easily use it to store its assets.

@brav0 about CoC: It is not about replacing configuration, my point is to provide some convention for a basic upload functionality so it easily works for someone that does not want to customize it. I’m talking about something similar to how Assetic dumps its assets or how Symfony stores its sessions: if you are not interested in the details, it just works.

I do agree that this discussion could however be moved elsewhere.

skler commented Aug 29, 2013

@boonkerz please have a look to my proposal. I guess that everything depends on kernel is in app folder. Private bundles and libs could be shared between apps.

Contributor

I am concerned that we have /bin/ in the .gitignore file but it will now include files that should not be ignored.

Also, perhaps related, at OpenSky we have multiple console scripts, among them the standard console but also one called build that uses only symfony/console and does not initialize the app container, which takes a few seconds.

Perhaps it makes sense to have one bin/symfony that gets installed via composer which calls services from a container defined by Symfony. This script would include all Symfony commands, including an init:console command, which would create your application's console based on a Twig template that could be easily overridden. Generation of this script could be added to post-install-cmd and post-update-cmd. This would allow us to continue .gitignore-ing the contents on /bin/.

PS: For the voyeurs among us, we also use an init:front-controller command which uses a Twig template and has a few options for customizing what you want (i.e. --cache --apc), and a web/*.php entry in .gitignore. This is a firewall to prevent dev controller from sneaking into production.

gnugat commented Aug 29, 2013

@kriswallsmith +1 except on ignoring /bin/: I think that all user's script should go into /bin/ (e.g. install.sh, test.sh, or even OpenSky's build console).
This ignore rule is only there because currently vendors scripts are put into /bin/: maybe it's time to put them back where they belong (/vendor/bin).

@skler yea i prefer this because apps are more seperated

It would be nice if all scripts were available at the same place.

If we want to ignore the bin folder and still have user scripts, they could
be put in *Bundle/Resources/bin.

As of now, Composer requires every exported binary to be explicitly
declared, but maybe we could ask them if they want to support the
declaration of a folder of binaries.

It could treat files ending with a slash as a folder.

Example:
{
"bin": ["src/Acme/DemoBundle/Resources/bin/"]
}

Or just commit vendor scripts, afterall, we have a composer.lock so it's not the end of the world. It just means committing vendor stuff (the reason I believe this isn't done is it's faster to use composer on different distros and avoids submodules issues but that doesn't really apply to bin files). I'm personally not a fan of vendor/bin. CC @Seldaek

Member
Seldaek commented Aug 29, 2013

You can put the composer bins in bin/ just fine. The only problem is
that you should indeed gitignore that directory. It's not a huge deal
though, it just means that if you want to add one more of your
binaries in there to git tracking you must do git add -f bin/foo to
bypass the gitignore. Not the end of the world IMO, but it's mostly an
education problem.

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 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.

Member
stof commented Aug 30, 2013

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

@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.

Contributor
breerly commented Oct 5, 2013

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

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 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 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 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 👍.

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.

Member
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 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 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é

@andrerom andrerom referenced this issue in ezsystems/ezpublish-community Jan 26, 2014
Closed

Make the EzPublishKernel /app extensible #97

Contributor

👍 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.

Member
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 fabpot added a commit to sensiolabs/SensioDistributionBundle that referenced this issue May 9, 2014
@fabpot fabpot feature #118 Add new directory structure handler (romainneutron)
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
4ef8487
@fabpot fabpot added a commit that referenced this issue May 9, 2014
@fabpot fabpot feature #641 Add new directory structure hook (romainneutron)
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
f3f0fea
@fabpot fabpot closed this May 9, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment