-
Notifications
You must be signed in to change notification settings - Fork 39
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
Composer install #188
base: master
Are you sure you want to change the base?
Composer install #188
Conversation
I'm not sure replacing Elefant's autoloader completely is the right approach, because it means the class map needs to be regenerated every time you add a class to an app. Having the one fall back to the other isn't so bad though, since both autoloaders are pretty fast and lightweight. Having said that, I would like to use Composer so we don't have to manually keep those libraries up to date ourselves, and I like the post-install permission updates too. But what's stopping me from requiring Elefant sites to use Composer is that I don't want them to have to run |
The Symfony project distributes 3 ways
I'm gonna guess that their methodology is pretty well vetted. How about I mess with this just a bit more and see if I can't get it closer to what you want. |
Sounds like a zip with vendors plus a composer-based install would be a good solution. I was playing with Composer a bit more and I didn't realize the upgrade process was so rudimentary (unlink then pull a new copy). If you add a new file to an app that's not part of its original source, it will be deleted when Composer updates the app. That's already not recommended for apps (which is why we have overriding configs and handlers), but that approach is too simplistic for Elefant itself, as it will almost certainly wipe someone's important files. So I wonder, does installing via |
This is just a suggestion, because I was playing with it and it works quite well and I thought you'd be interested in what I found. To make composer work, you need to make composer.json, composer.lock, lib/vendor, lib/vendor/composer, and lib/vendor/autoload.php writable by the apache user. since this simply runs composer as Apache. On my systems this required my user and Apache to be members of the same group and the files to be group writable, 775 rather than 755. This also requires that composer be installed in Needs more work, obviously. But I'm moving on to other less intrusive stuff. |
This is pretty cool, although the permission requirements and regenerating class maps sound like they could add confusion for less techie users, but still a really neat solution. I'm going to keep the issue open since I don't think we should make such big changes to how things work before 2.0 is out, but that way we can explore install/update approaches post-2.0. And sorry about the slow responses lately, should be back to normal next week once I'm not on the road any more :) |
This provides an update relate to issue #184
I started to notice that the vendor libs were getting a little out of date and once I updated analog (for instance) through Composer I had 2 copies. Then I also needed a composer-managed autoload in addition to the standard one. So I experimented a bit and found that I could simply replace the standard autoload with the Composer autoload, with a few tweaks.
So this PR does that, adds the vendor libraries to composer.json, removes the duplicated libraries, and while I was at it I threw in a script to update the permissions and run phpunit after the install. All the PHPunit tests pass and a basic install works, including installing the Newsletter app.
This may fall under the rubric of "If it ain't broke, don't fix it", but it was a little broke.