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

Comments

Projects
None yet
@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

This comment has been minimized.

Show comment
Hide comment
@Tobion

Tobion Aug 19, 2013

Member

Duplicate of #501 and #325

Member

Tobion commented Aug 19, 2013

Duplicate of #501 and #325

@lyrixx

This comment has been minimized.

Show comment
Hide comment
@lyrixx

lyrixx Aug 19, 2013

Member

I'm totally +1 with this ;)

Member

lyrixx commented Aug 19, 2013

I'm totally +1 with this ;)

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Aug 19, 2013

Member

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

This comment has been minimized.

Show comment
Hide comment
@webmozart

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

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

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Aug 22, 2013

Member

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
Member

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

This comment has been minimized.

Show comment
Hide comment
@peterjmit

peterjmit Aug 22, 2013

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

peterjmit commented Aug 22, 2013

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

@iansltx

This comment has been minimized.

Show comment
Hide comment
@iansltx

iansltx Aug 22, 2013

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

iansltx commented Aug 22, 2013

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

@lsmith77

This comment has been minimized.

Show comment
Hide comment
@lsmith77

lsmith77 Aug 22, 2013

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Aug 22, 2013

I like that. It just makes more sense.

ghost commented Aug 22, 2013

I like that. It just makes more sense.

@tipyy

This comment has been minimized.

Show comment
Hide comment
@tipyy

tipyy commented Aug 22, 2013

+1

@lsmith77

This comment has been minimized.

Show comment
Hide comment
@lsmith77

lsmith77 Aug 22, 2013

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad 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

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

This comment has been minimized.

Show comment
Hide comment
@kimausloos

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

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

This comment has been minimized.

Show comment
Hide comment
@mbadolato

mbadolato Aug 22, 2013

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Aug 22, 2013

Member

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

Member

fabpot commented Aug 22, 2013

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

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Aug 22, 2013

Member

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

Member

fabpot commented Aug 22, 2013

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

@everzet

This comment has been minimized.

Show comment
Hide comment
@everzet

everzet 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

?

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

This comment has been minimized.

Show comment
Hide comment
@webmozart

webmozart Aug 22, 2013

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

webmozart commented Aug 22, 2013

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

@mbadolato

This comment has been minimized.

Show comment
Hide comment
@mbadolato

mbadolato Aug 22, 2013

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@simensen

simensen Aug 22, 2013

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@matiangul

matiangul Aug 22, 2013

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

matiangul commented Aug 22, 2013

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

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Aug 22, 2013

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@kriswallsmith

kriswallsmith Aug 22, 2013

Member

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

Member

kriswallsmith commented Aug 22, 2013

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

@lsmith77

This comment has been minimized.

Show comment
Hide comment
@lsmith77

lsmith77 Aug 22, 2013

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@webmozart

webmozart Aug 22, 2013

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

webmozart commented Aug 22, 2013

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

@mykehsd

This comment has been minimized.

Show comment
Hide comment
@mykehsd

mykehsd Aug 22, 2013

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

mykehsd commented Aug 22, 2013

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

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Aug 22, 2013

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@dcsg

dcsg Aug 22, 2013

Member

👍 for the new directory structure.

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

👍

Member

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

This comment has been minimized.

Show comment
Hide comment
@rande

rande 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

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

This comment has been minimized.

Show comment
Hide comment
@peterjmit

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

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.

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Aug 22, 2013

Member
├── 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
Member

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

This comment has been minimized.

Show comment
Hide comment
@hhamon

hhamon Aug 22, 2013

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@hussani

hussani Aug 22, 2013

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

hussani commented Aug 22, 2013

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

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Aug 22, 2013

Member

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

Member

fabpot commented Aug 22, 2013

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

@rande

This comment has been minimized.

Show comment
Hide comment
@rande

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

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.

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Aug 22, 2013

Member

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

Member

fabpot commented Aug 22, 2013

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

@lsmith77

This comment has been minimized.

Show comment
Hide comment
@lsmith77

lsmith77 Aug 22, 2013

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.

Contributor

lsmith77 commented Aug 22, 2013

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

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Aug 22, 2013

Member

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

Member

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.

@johnkary

This comment has been minimized.

Show comment
Hide comment
@johnkary

johnkary Aug 22, 2013

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"

johnkary commented Aug 22, 2013

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"

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Aug 22, 2013

Member

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

Member

fabpot commented Aug 22, 2013

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

@rk3rn3r

This comment has been minimized.

Show comment
Hide comment
@rk3rn3r

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

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

@lavoiesl

This comment has been minimized.

Show comment
Hide comment
@lavoiesl

lavoiesl Aug 28, 2013

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

lavoiesl commented Aug 28, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@skler

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

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.

@kriswallsmith

This comment has been minimized.

Show comment
Hide comment
@kriswallsmith

kriswallsmith Aug 29, 2013

Member

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.

Member

kriswallsmith commented Aug 29, 2013

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

This comment has been minimized.

Show comment
Hide comment
@gnugat

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

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

@boonkerz

This comment has been minimized.

Show comment
Hide comment
@boonkerz

boonkerz Aug 29, 2013

@skler yea i prefer this because apps are more seperated

boonkerz commented Aug 29, 2013

@skler yea i prefer this because apps are more seperated

@lavoiesl

This comment has been minimized.

Show comment
Hide comment
@lavoiesl

lavoiesl Aug 29, 2013

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/"]
}

lavoiesl commented Aug 29, 2013

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/"]
}

@michaelcullum

This comment has been minimized.

Show comment
Hide comment
@michaelcullum

michaelcullum Aug 29, 2013

Member

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

michaelcullum commented Aug 29, 2013

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

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Aug 29, 2013

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@gnugat

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

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

This comment has been minimized.

Show comment
Hide comment
@kor3k

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

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

This comment has been minimized.

Show comment
Hide comment
@stof

stof Aug 30, 2013

Member

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

Member

stof commented Aug 30, 2013

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

@evillemez

This comment has been minimized.

Show comment
Hide comment
@evillemez

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

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.

@breerly

This comment has been minimized.

Show comment
Hide comment
@breerly

breerly Oct 5, 2013

Contributor

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

Contributor

breerly commented Oct 5, 2013

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

@kor3k

This comment has been minimized.

Show comment
Hide comment
@kor3k

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

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

This comment has been minimized.

Show comment
Hide comment
@sstok

sstok 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

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

This comment has been minimized.

Show comment
Hide comment
@kor3k

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

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

This comment has been minimized.

Show comment
Hide comment
@lemoinem

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

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

This comment has been minimized.

Show comment
Hide comment
@yellow1912

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

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

This comment has been minimized.

Show comment
Hide comment
@stof

stof Oct 10, 2013

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@patie

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

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

This comment has been minimized.

Show comment
Hide comment
@rk3rn3r

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

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

This comment has been minimized.

Show comment
Hide comment
@cordoval

cordoval Mar 13, 2014

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@wouterj

wouterj Mar 13, 2014

Member

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)

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 added a commit to sensiolabs/SensioDistributionBundle that referenced this issue May 9, 2014

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

fabpot added a commit that referenced this issue May 9, 2014

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

@fabpot fabpot closed this May 9, 2014

@weaverryan weaverryan referenced this issue May 3, 2015

Closed

[3.0] Move AppBundle/* into app/ #803

0 of 7 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment