Composer

OpenEMR Development
#1

wakie87 wrote on Tuesday, July 12, 2016:

Discussion continued from github: https://github.com/openemr/openemr/pull/150

Bradys last comment raises a lot of valid points:

As with bower and the front-end assets, I propose baby steps. This will at least be much simpler since there will only be 1 version of each package...

Recommend starting with placing plan on the wiki page:
http://www.open-emr.org/wiki/index.php/Composer

For an example, see the bower page:
http://www.open-emr.org/wiki/index.php/Bower

I see no reason to rock OpenEMR's world with separate repos and forced developer/tester composer education so early in the game. When implementing something, should also think of the downstream effect. For example, resources to:
1. convert githib openemr project to an organization
2. convert demo farm to build package
3. convert package builder script to build package
4. testing of packages will entirely fall on the person making the release
5. requires all developers(newbie, experienced, young, old) to use composer to have a working package. Thus need documentation for developers.
6. testers with minimal development experience whom test the master codebase frequently (ie. for example Arnab) will need to use composer to have a working package. Thus need documentation for non-developers.

Why not first just get composer in and start migrating packages to it (while tracking this on the wiki page). Then could always decide to go the build route in the future with very small amount of work, which would just involve deleting files and adding a phpmyadmin repo (ie. why are we making this decision now?).

If still wish to push for this so early in the game, then recommend discussing it on the forums.

-brady

Just wanting to continue the conversation here as I feel like we need to implement composer the right way from the very start.

#2

wakie87 wrote on Thursday, July 14, 2016:

Plan of attack for getting composer into the project:

  1. Commit the vendor directory to the codebase initially until we get composer to work with demo and build scripts. The workaround is to add a .gitignore line that removes all .git directories within your vendor directory. So add this line to the .gitignore file at the same level as composer.json and vendor/: vendor/.git
  2. Get the demo and build scripts to bring in composer dependencies and package them up and test.
  3. Make sure documentation on how to use composer is upto date and developers are aware of upcoming changes
  4. Once this is done we can remove vendor directory from the codebase
#3

bradymiller wrote on Thursday, July 14, 2016:

Hi,

Quick question. Will there ever be .git directories brought in via vendor since we are bringing in stable versions and not the development/unstable versions of the packages?
Even so, the .gitignore seems like a safe thing to do since multiple .git directories in a git repo doesn’t sound good.
Do you mean something like

vendor/*/.git

-brady

#4

wakie87 wrote on Thursday, July 14, 2016:

Yep,

According to https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md

Add a .gitignore rule (/vendor/**/.git) to ignore all the vendor .git folders. This approach does not require that you delete dependencies from disk prior to running a composer update.

-Scott

#5

bradymiller wrote on Friday, July 15, 2016:

Hi,

Thanks for the explanation.

To keep things simple, should we enforce a rule to only place things in vendor via composer and that don’t require modification?

-brady
OpenEMR

#6

wakie87 wrote on Friday, July 15, 2016:

Absolutley,

While transitioning over to using composer as a dependency manager, AND while we are commiting the vendor directory to the codebase, ALL dependencies should be brought into the project using the composer install command.

A good article to read regarding the vendor directory and what it does:
https://igor.io/2013/09/04/composer-vendor-directory.html

ALL DEVELOPERS: Eventually the vendor directory will not be included So don’t go editing files in this directory and commiting them. We are still in the beginning stages of decided on if and how we build/release with vendor folder etc. Check out the wiki for more details. http://www.open-emr.org/wiki/index.php/Composer

Scott