Why does the default laravel4 have the composer.lock file included in the .gitignore repo?
It seems to contradict composers recommendations to commit this file into VCS. I was wondering if there was something I didn't know that justified this?
According to the author of Laravel here https://github.com/laravel/framework/issues/1412:
It is recommended for your own apps, not for frameworks.
It's not clear from the question if you meant the framework or the app. Instead of asking for a clarification, I decided to write this instead for future confused users.
The problem is, it's ignored not only in the framework but in the app too. The app is what you get when you install Laravel as a project (i.e. not for the purposes of developing it and sending pull requests but for using it in a project of yours).
In contrast, the Symfony project makes a distinction here and doesn't include the lock file in the .gitignore of the the Symfony Standard Edition distribution (the app) unlike the Symfony framework.
There are already at least two issues and one pull request regarding composer.lock: issue 1696, issue 2293 and PR 2591.
Related
I regularly use Laravel to build applications. Recently, I have started using Lumen to build microservices.
One thing I notice with Lumen, is that I often only need to create 2-3 files, and edit a further 2-3 (providers, configs and routes). In total, I am editing or creating 5-6 files.
It feels to me that my git repositories for these microservices would be way cleaner if they only included the changed files, and then I merged with the Lumen framework during the CI build/deploy.
Does anyone have any experience with doing this? What are the pros/cons?
I build many API services with Lumen, and I always have the entire project on git repo, and when I make changes locally, I pushed it to GitHub and from the server i just take a pull. I wouldn't say there are necessarily pros or cons, just different ways of doing things
I have been developing in Codeigniter for awhile now. I have recently read that Laravel is currently the most modern and best framework. I am interested in learning it for my next project. I'm hoping that someone could help to answer some questions that I have about Laravel.
1) How would I host it? Laravel seems to rely on composer a lot and that requires a terminal. For CI, I just download a folder and load it up to my Webserver and I can run it.
2) Dev environment. I have been using Netbeans that is connected to my server and it can push updates instantly. I want to connect it to git soon for some versioning as well. Is it the same for Laravel? How would I update it?
Same here, I have been developing Applications in Codeigniter 2,3 for past 5 years and now I am learning Laravel and have starting making beginners level application in Laravel Here are my findings which might help you
Difficulties
For Codeigniter Developer, Instantly playing everything by using router is kind of difficult. Although router is used in codeigniter as well
Installing and setting up Laravel seems like a tricky and very lengthy job especially the use of composer which is an extra thing as compared to codeigniter which is just download and uncompress or copy paste installation procedure.
But Why Laravel?
Object Relation Modeling - Eloquent ORM
We can easily create relations and joins with query builder or active records in codeigniter but to enforce referential integrity in database, we have to write triggers in our database or define relations. Luckily in Laravel the relations are made with one line of code and does a lot of job. Whereas in Codeigniter that's a lot of manual code writing.
Integration of off the self Packages.
There are thousands of developed packages readily available on packagist, which is a repository composer uses to download software packages. You just have to write one or two lines of code at composer terminal and it does all the rest, create models, controllers, views. All you have to do is include them or change the styling as per your layouts.
Think of Laravel as a PHP framework for extremely lazy developers who want to write very less and re-usable code and do lot of work from it.
Learning Resources
Laravel 5.2 from Scratch that's the one I started with, excellent course and Modern Web Development with Laravel
Uploading on Shared hosting
Click here for tutorial
After some fiddling building a package for a project we've realised there's some issues with doing what we need to achieve as per Laravel 5 package development clarity
Maybe I should rather explain my goal and someone can suggest a direction to head in.
We've built a Laravel 5 application that now needs to be "re-used".
We had to modify Laravel and implement an Eloquent type base model as our data-source is actually C# Web Services. At the point the call would be made to a database we intercept this and make an "API" call to SOAP.
The major difference will be CSS, maybe some JS & content but all the routes/controllers/models will remain the same across all projects. Most configuration comes from endpoints.
Initially we considered creating multiple asset repositories for each site's styling and have a base repo which is the core Laravel project that gets included. This seemed to get quite complex as we couldn't simply just have a repo in a repo due to branching and multiple directory issues.
We then started experimenting with the idea of building the "core" as a Laravel package but we seem to constantly hit walls. The latest problem being including models in the package. For the models to be called we are using the root projects config/composer to access these models instead of just the service provider. It feels like the package is becoming to tightly coupled to the project config.
Are there any better ways of going about what we are trying to achieve?
Edit:
I forgot about the multiple branch solution on 1 repo but wouldn't this get ugly when it comes to feature development? Example:
master (core with releases that get pulled into _site*)
dev (master dev)
feedback-form (eg. master branch feature)
_site1 (root site with releases)
_site1-dev (_site1 dev)
_site1-reskin (eg. _site1 feature)
_site2 (root site with releases)
_site3 (root site with releases)
This leaving quite a bit of destructive merge power in the developers hands? Read access with pull requests maybe a solution to this?
So after some R&D it seems the best solution right now is to have 1 repo with multiple branches. Developers have read access and have each developer creates his own fork. Developers create pull requests and sync to parent repo through "upstream" remote and developers sync each others forks through additional remotes.
Seems a little clumsy but probably "cleanest" option.
First of all, I'm a complete newbie to Composer. I've been trying it out since it's a sounds awesome and mainly because Zend Framework 2 uses it.
Zend Framework 2 is actually also the reason for this thread.
It get the basics of Composer. But with my current server setup I have a request, which I can't seem to figure out if possible.
Let me explain.
I have multiple Zend Framework 2 projects:
/home/morten/sites/Project-1/
/home/morten/sites/Project-2/
/home/morten/sites/Project-3/
All of these projects should be running ZF2. When running composer in each project - each of them get their own separate download of the ZF2 Library files. Which is a bit redundant with my setup.
I have a complete and up-to-date download of ZF2 Library located at:
/var/www/shared/Zend/
And my php.ini has that path added to PHP's include_path, so the whole ZF2 library is available for all the three projects.
IS IT POSSIBLE to make Composer use in it's setup. Because if I try to change stuff and try things out in the composer files, then it just re-downloads Zend because it's a required component for other modules.
Can this be done? And if yes, how can I do it?
Hope I have explained myself good enough for you guys to understand what I'm trying to do and want :)
Thanks a lot in advance!
Regards,
Morten
You might be able to have one composer.json file stored in /var/www/shared/Zend, where you would put your dependencies and use Composer do manage them. Then all projects could include the same autoloader.
However, I wouldn't recommend that approach:
Your project's dependencies (composer.json) should be stored with your project. If you want to install your project somewhere else (for instance if you want to move one project to another server), you are missing the composer.json to install the required dependencies.
It will not be possible to update the dependencies of one project, without updating the dependencies of all other projects. If you want to introduce a new feature in Project 1, which requires a new version of a certain dependency, all other projects will get this new version as well - which might introduce backward compatibility breaks if an older feature that Project 2 relies on, is no longer supported. Since you can only have one version of each dependency, it is not possible for two projects to have different versions of the same dependency.
This approach might be useful if all projects will have the exact same functionality and code, but in that case you should probably merge them into one project.
In all other cases, I would suggest to use Composer the way it's supposed to be used: give all projects their own composer.json file and let Composer download the dependencies per project, in each project's vendor directory. The downside is that it'll cost you a little more disk space, but you'll get a lot of flexibility for it in return.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 months ago.
Improve this question
I'm starting to use Laravel 4 seriously in my projects. I understand that this framework offers many advantages when developing RESTful applications. But I understand that there is no consensus about how do deployment / publishing and app using Laravel. I am still using FTP to transfer files to my Production host. But my question is, Is there any standard way to do the same but from Laravel? I am faithful believing that with a little ingenuity one can create something like php artisan publish [Production server name and SSH credentials] as parameters.
I have read something interesting from Anahkiasen/rocketeer and Christopher Pitt, both great sources but there is a consensus or standard way to publish applications using laravel?
This is not really a Laravel problem/question, you have to ask on a dev-ops forum what they would do to deploy a PHP application like yours.
Your Laravel application is basically PHP application, some packages are provided by Composer, so it's more a Composer application than a Laravel one, but you might have some Laravel needs, like executing php artisan migrate, or any other artisan command to post-deploy your application, or not, so, it's more a requirement of your application than Laravel, right?
I developed a package to do my deployments, Deeployer. The intent of this package is, everytime I push my application to the production (or staging) branch, Github will fire a hook that tells my server to do whatever it needs to deploy my application to my own VPS. In a basic deployment it will:
1) git pull the repository
2) Execute composer update to update my vendor folder
3) Execute bower update to download whatever js or css I've installed
4) Execute php artisan migrate to upgrade my database schema
5) Execute chmod and chown to fix whatever permission mess those commands might have made to my directories while downloading files
See? Those are things that are very particular to my deployment structure, that's why I don't really think you are going to find consensus about a deployment app. When Anahkiasen first build Rocketeer, someone shout: "Why are you doing this if we already have Capistrano?".
Yesterday I bumped into this one: http://www.deployhq.com/packages, used by Ben Corlet from Cartalyst and other nice guys.
There's also Rocketeer: http://rocketeer.autopergamene.eu/.
Don't forget that Laravel itself has it's own SSH Remote component (I used it on Deeployer and Rocketeer uses it too), that might help you do whatever you need to deploy your app.
So, you better think what are your deployment needs and find your way, using a package, app or just Laravel.
There are a lot of deployment tool, like Capistrano. I recommend you to take a look at Deployer: it's has simple api, bundled with recipes for popular frameworks and apps, and can do 100% parallel task execution. Also it requires only for PHP.
deployer.org
github.com/deployphp/deployer
How to deploy Laravel
Here is an example of simple task:
task('my_task', function () {
// Your tasks code...
});
Also it has a good quality code:
You may want to check out Rocketeer:
http://rocketeer.autopergamene.eu/
If you are asking for a standard, I don't think there is one. But an alternative from FTP, well, have you considered using git as a way to deploy your site to production?
Here is how you do it:
http://danbarber.me/using-git-for-deployment/ (Link is broken)
https://www.digitalocean.com/community/tutorials/how-to-set-up-automatic-deployment-with-git-with-a-vps
Basically the summary is that you have a bare git repository, your own local repository and your production repository.. now by configuring the correct hooks, when you push to the bare git repository, a hook in it will tell the production repository to pull the most recent changes you commited down to the production. And in addition, setting up the correct credentials in your config depending on the environment.. you can create a new folder ex. app/config/production and app/config/stage so that you can easily run the application even while switching on both servers..
I'm not so sure about a standard way either. You do have Forge and Envoyer that work with Laravel, so that is something to look into.
Here is a way to deploy Laravel using Rocketeer and Git. It is very easy to setup and allows you to use multiple servers (think staging, production, etc.)
http://dericcain.com/blog/deploying-laravel-5-with-rocketeer