Move drupal-composer-project repo to drupal-composer org

Posted by kasperg on January 29, 2015 at 2:24pm

The drupal-composer-project template currently resides within the Reload organisation on GitHub.

derhasi has been doing a great job keeping his fork up to date with his latest development and the fork is currently a better template for starting out new Drupal 7 projects with Composer.

How about we transfer the repository to the drupal-composer organisation and merge in derhasis changes to the composer.json file?

I still think some of the documentation in the original repo is worth keeping around for others getting started with Drupal + Composer so I think we should update that accordingly.

Comments

Sounds great. I think we

Posted by webflo on January 29, 2015 at 3:07pm

Sounds great. I think we should add the site template from tstoeckler/David Barratt as well.

Agreed. Adding

Posted by kasperg on January 30, 2015 at 4:31am

Agreed.

Adding https://github.com/tstoeckler/drupal-site-template for Drupal 8 would be great. I looked into Davids repos on GitHub and did not find one with the same purpose. Do you have a link to the project you are referring to?

When we add both we need to address how we handle the Drupal 7 vs. 8 difference. The templates are quite different. As I see it we could either have one repo with a branch for each Drupal version or a repo for each version.

That's a great idea. @kasperg

Posted by derhasi on January 30, 2015 at 12:18pm

That's a great idea. @kasperg do you need anything from us to move the ownership? Is it possible to go from "reload/drupal-composer-project" to "drupal-composer/drupal-project"?

In my repo I shortened the README, as some parts seem to be updated from my perspective. We should definitely "refactor" that.

Regarding Drupal 7 & Drupal 8, I would keep that in the same repo in different branches, as I think a default implementation should not really vary that much. How to achieve that we could discuss in the github issues.

Need GitHub admin rights

Posted by kasperg on February 2, 2015 at 10:11pm

I need temporary admin rights to the drupal-composer organization on GitHub to make the transfer.

Regarding my drupal-site-template

Posted by tstoeckler on February 2, 2015 at 11:47am

I would love to transfer the Drupal site template to the Composer group, thanks for the endorsement!

It's currently fairly "barebones" (i.e. it doesn't do much) and I would like to add some more "features" in the future, especially regarding security best practices. I.e. it would be awesome if we could set it up in a way that private files and configuration files are stored outside of the webroot by default (just to name one example). But we can always improve in the future and it currently works, so I see no reason to not do the move.

One thing that might be a little contentious is the web directory. I think it's fairly undisputed that putting Drupal in a subdirectory of the Git repo is considered a best practice, so the directory itself is not contentious, I think. It's just that the name web is arbitrary and some people might like to use a different name. E.g. I had public at first, but then thought that might be confusing because Drupal has the public stream wrapper (i.e. public://foo vs. public/foo). Other choices might be docroot, for example. Since there's really no way to make this configurable, we have to choose one, and I don't know of any better choice than web; just wanted to point out that this might be an issue.

I would vote for docroot. We

Posted by hussainweb on February 2, 2015 at 11:54am

I would vote for docroot. We use that on sites hosted on Acquia and also while developing on Projspace, a platform we use for development (and sometimes hosting) internally at the organization where I work.

web

Posted by fago on February 2, 2015 at 5:33pm

Joining the bikeshed, I love "web" - we are using web for a while already. Anyway, I guess it's good to have it conifgurable / adaptable.

I'm thinking "web" is a good

Posted by derhasi on February 2, 2015 at 11:54am

I'm thinking "web" is a good directory name to start with. As the template is only a template, it should be no problem for others changing that in their specific project or their specific template. In addition we could cover changing the "web" folder in the README.

I agree. web is also the

Posted by kasperg on February 2, 2015 at 10:19pm

I agree. web is also the default directory name for Symfony projects.

I fear that if we dive into adding scripts for this and that we risk drifting into what should be a proper Drupal project installer as discussed elsewhere.

switch.sh

Posted by tstoeckler on February 2, 2015 at 4:35pm

Yes, documenting that is certainly a great idea. I also thought about a little script that does the switch for you (i.e. not only mvs the directory but also updates composer.json and composer.lock.

docroot vs web vs public_html cs htdocs

Posted by hedinfaok on February 2, 2015 at 6:01pm

BLARGH! :D

I use "docroot" for the same reason as above: Acquia (https://docs.acquia.com/cloud/manage/code).

When I looked at the OP, I thought "Wow, this is a great project. Nuts. It doesn't use 'docroot'."

The script to move files and directories around an update the composer.* files is very useful, but we still have an underlying problem: we can't agree on the name of a folder that contains our publicly accessible files.

We can't look at web servers for guidance either. Apache's default location and naming changes for each platform specific compiled version.

So this just really bothers me. We can't use any known justification. It's just "web" or "docroot" or "public_html" or "htdocs" or "name of project that uses drupal" or "src" or "drupal"

My only justification for "docroot" is that I can't change the default document root on Acquia, so I either use "docroot" or create a symlink "docroot -> web". Symlinks confuse my devs in Windows, so I prefer to stay away from them in a codebase.

"Web" and "www" are good alternatives, too.

... and I know that we're not the only ones that have had this discussion, so that bothers me too.

END BLARGH! :D

I guess we could add a plugin

Posted by derhasi on February 3, 2015 at 8:14am

I guess we could add a plugin that will allow to change the root with the script event "post-root-package-install". But for now we should simply start with one name. As I said, that project always will be just a template, as every team might have some different needs.

@kasperg, do you need some help to move your repo or how shall we proceed? You can meet me in IRC if you want :)

I'd be wary of a post-install fixup script

Posted by greg.1.anderson on February 3, 2015 at 5:30pm

It could complicate the composer update operation if the end result was installed code in a location that differed from what was specified in composer.json. You could always fix it up again with a pre-update function, but I think it would be better to just fix up composer.json prior to composer install. The composer-generate script could do this, for example.

drupal-composer-project transfered

Posted by kasperg on February 3, 2015 at 9:18pm

I have transferred the project to drupal-composer.

If we add drupal-site-template as a separate branch we should decide on a shared project name and submit the package on packagist.org.

I will abandon reload/drupal-composer-project on packagist as well but it would be nice to be able to refer to an alternate package.

I will try to make time for IRC going forward.

I put a PR together with the

Posted by derhasi on February 6, 2015 at 11:35am

I put a PR together with the important changes of my fork: https://github.com/drupal-composer/drupal-composer-project/pull/5 .

I would go for drupal-composer/drupal-site-template or drupal-composer/drupal-project.

drupal-composer/drupal-project

Posted by kasperg on February 11, 2015 at 9:14am

I opened a pull reques to rename to drupal-composer/drupal-project.