Allow per-project installations for Homestead 2

[jfelixetcetera]

With the rewrite of Homestead v2, it is now considerably more difficult (if not impossible) to share development environment code on a project. One of the key benefits of Vagrant is committing the Vagrantfile to a repository and thereby having all developers working from the same environment. (Isn't that the whole point of Vagrant?) But with Homestead 2, all your config lives in your own personal ~/.homestead directory, and is non-shareable.

I was never really a fan of the instructions for Homestead 1 which advocated using a single, central clone of the homestead repository. (Am I really the only one who uses separate homestead boxes per project? Do other people prefer not to segregate environments? That's like developing on our own little shared hosting boxes, allowing different project code and installation requirements to co-mingle.) But at least with the original Homestead it was possible to put the homestead files inside your project's repo (I used subtree add, since I'd customize the provision scripts.) With Homestead 2 and after.sh, the ability to customize the environment is getting better (and somewhat more reproducible), but taking a huge step backwards in shareability.

While bundling homestead commands as a composer project is great, further centralizing config seems to be taking Homestead in a wrong direction...

[jfelixetcetera]

After further thought, I've come to believe Homestead is designed around having developer-centric environments, as opposed to project-centric environments. Which seems entirely backwards to me.

Sure, it works if you're developing a very basic application* and the stock Homestead install works out of the box for your project, or if you're working alone. But I've worked on very few projects that have the same server-side software requirements or are limited to a single developer. Need to add elasticsearch? Switch to MariaDB? What about build tools other than grunt or gulp? Want to use the awesome maildev during development? Homestead allows you to customize your development environment, and do so in a way that isn't affected by your host system. But it doesn't allow you to share those customizations. Which is a huge step backwards from the massive improvements (and productivity gains) Vagrant has brought to the development process.

* I assume some will argue that the default Homestead box is designed to work with Forge, which is very probably true. But will Forge really never get the ability to more flexibly add provision steps and customize server environments during deployment (recipes are a great start, but there's a lot more potential there)? Maybe not, but if not, it will remain relatively niche. I love Homestead and Forge because they provide clean, solid base environments on which I can develop. But if I have to give all that up and start from scratch as soon as I need to customize my environment, that doesn't make me code very happy. I hope we can figure out a better way to manage development and deployment environments using the full power of the tools we have...

[jasonlewis]

Couldn't you still use a subtree for the latest version though? The repository is still there: laravel/homestead

I'm sure you're not required to install the global Composer package and use the homestead command.

[jfelixetcetera]

Not really. The Vagrantfile already assumes a ~/.homestead directory. And I can only guess it's going to go more down this path.

On top of that, the subtree solution isn't a great one to begin with. It's hard to maintain as soon as you need to make changes to the Vagrantfile or homestead.rb, in which case you're basically giving up on future upstream changes. Which, from what I can tell, is one of the reasons for the changes in Homestead 2.

But I just think it's limiting Laravel development more than expanding. What I'd be hoping for is more of a modular system, where concepts like after.sh are a bit more flexible and can be loaded from a project (or also a home directory if desired). Something like the way .gitconfig and other configuration systems work, maybe using Vagrantfile inheritance. It adds complexity, but there's no reason it needs to be exposed to most developers. If working out of a single shared box is fine for your needs, great. I just wish Laravel offered support for better practices from the start.

[jasonlewis]

Ah you're right. I didn't even take a look in there.

I agree that more flexibility for more advanced developers should be as big a priority as making it easy for newer developers to quickly get up and running.

But I'm hardly one to comment on how it would be achieved as I'm not exactly a pro at Vagrant or provisioning servers. :grinning:

[thattomperson]

I was about to propose a way to fix this in your ~/.homestead/homestead.yaml file you could have a projects (name negotiable) array that has file paths to the root of a laravel install and it can read the a homestead.yaml for the site specific stuff like provision scripts and database names and site public directory and local url

just an idea I will be ready to submit a pull request later about this

[djtarazona]

Agreed, I prefer to have separate boxes per project and am currently rolling my own solution as well. Homestead 2 indeed makes this more difficult. I want my project to configure the box.

[jfelixetcetera]

@ThatTomPerson That would be an improvement over the status quo, but not really go far enough to be too useful. How many settings can you really put into Homestead.yaml? I mean, all of them benefit from being project-specific, but are less important settings that be maintained by all developers across a project (though I advocate they absolutely still be shared settings). At a minimum, after.sh and aliases also need to be able to be project-specific, but this would be much cleaner if these two extra script files had been implemented as part of Homestead.yaml` to begin with.

A bigger problem though is Homestead.rb (which is basically the actual Vagrantfile. Many projects of could really benefit from the ability to add actual Vagrant steps (I add the DNS manager landrush to mine, for example).

Plus, there's the other problem of needing to manage a central list of all your projects within the main ~/.homestead/Homestead.yaml file.

What I'd really like is to be able to run homestead up from within a project repo and have it automatically use project-specific config if it exists, with no special steps required. Have the ability to inherit the main Vagrant steps, but add to them (thus ensuring you can still stay in sync with core Homestead updates). Use project-specific Homestead.yaml, after.sh, and aliases if they exist. That would be much closer to a more flexible system that could still work the way it currently does if users want that (though personally I'm not a fan of recommending developers use a shared host model at all).

[thattomperson]

@joshuajabbour @djtarazona most people using homestead don't need all of the customisability of vagrant, they just go homestead up and everything works for them

I think homestead is targeted to people who may be a bit scared of the command line and prefer to work with things that they can see

if you want to run a application per vm then I think you should be using just normal vagrant

this is where is was trying to go with my changes now to configure homestead you will just edit the homestead.yaml in the project directory and not have to find it in a hidden folder or run a console command

and I was going to add a way for homestead to add that project file path by its self maybe with homestead import and then it will add the current working directory to the projects array and look for a homestead.yaml in that directory for the settings used by that project

[thattomperson]

maybe even if homestead included the laravel installer so that running homestead new [projectName] it could install a new version of laravel and then add it to homestead automatically

[jfelixetcetera]

Using words like "most" is ill-advised, as you have no way of knowing that. However, my main issue isn't that these changes to Homestead occurred at all, it's that they occurred in a way to make it unusable for those who do need more flexibility. Your proposed changes will help, but don't offer enough flexibility. Purestead does, but is a complete fork and therefore I'm not sure the benefit. I'll probably get around to extending Homestead using proper Vagrant inheritance...

[gvsrepins]

@joshuajabbour, I totally agree with you. The way homestead is going on is making it more difficult to share customized projects with a team. Will be much better if it follow the vagrant approach or as you say adds more flexibility of configurations per project.

[micflan]

Definitely agree with this. I've got many clients and many different projects; the beauty of Vagrant is being able to share those development configurations with the team, and to limit the impact of one environment on another. With Homestead 2 those key benefits no longer exist :-/

Purestead looks like it might be a better option for now. First I've seen of that; will be trying it out.

[andrewmclagan]

+1 Homestead seems to drift away from the core Vagrant principal of discreet project server environments, for reasons I'm yet to understand.

[EwanValentine]

+1 Agree with this. It's a nice idea, but it would be great to have the option to use Homestead as a standalone vagrant project as well.

[brpaz]

I agree with this as well. It would be great to have a .homestead.yml file per project. It could work like Vagrant does. homestead init would create a homestead.yml in your project root folder (similar to vagrant init) instead of using a global file.

For now, I am using only the homestead box directly with vagrant.

[ozanhazer]

+1

[joearcher]

Project specific Homestead environments are absolutely critical for our workflow. We will quite simply not be able to utilise Homestead 2 as it stands at present.

[b3nl]

+1

[thattomperson]

So question if you want homestead to work like vagrant why don't you just use vagrant?

EDIT the way I see homestead is it is not supposed to be for setting up projects, It is more of "I have an idea and I don't want to wait 2 hours for a vm to provision".

also 2 hours is accurate for me in Australia

if you want it to work like vagrant, use vagrant or purestead

At the moment with with homestead running just one vm is a good thing

[thattomperson]

The last commit on https://github.com/zoontek/purestead was today so it is being worked on and it uses the same Box that Homestead does so it is the exact same software stack

[b3nl]

i think, the discussion "if you want homestead to work like vagrant, than use vagrant" leads to nowhere. An example? Laravel (git)ignores the vendor dir per default but the default vm for laravel gives us no direct automatism to install the vendor dir?! Every team - my team, team of @joearcher, etc. - needs to implement provisioning additionally for getting even the minimum of loading the vendor dir.

[joearcher]

@ThatTomPerson I find your "I work this way, and so should you, or go elsewhere" attitude to this issue unconstructive and opinionated. "Use another product" is not an appropriate response to this issue. Because the product fits your needs does not make it appropriate for everyone, especially when the issue is with functionality which has been removed but was available in earlier versions.

[ozanhazer]

I've experimented lot's of frameworks since ruby on rails first came out, maybe 10 years ago from today, and what I like and amazed about laravel is there's a decent answer to virtually any common problem (which is the definition of a framework), without sacrificing flexibility and with great documentation.

Homestead is a good utility for building up the dev. environment but it sacrifices some flexibility this time and I believe this is a very common case.

Yes you can always set your own vagrant box or use an alternative but that's what we do with zend framework or symfony or any other popular framework, isn't it?

[franzliedke]

I agree it's a missing feature.

Vagrant supports multiple VMs per environment. Maybe this can somehow be used to allow for per-project VMs?

[thattomperson]

I'm not saying you cant use homestead I'm working in a group of 3, so homestead wouldn't work for us because if one person makes a change like installs Mongo how do you handle that??

homestead as it is, does not handle stuff like this, so I made some changes to homestead and just copy them into the root of my project you can see my changes at https://github.com/ThatTomPerson/homestead

this is more customisable and all configuration is now in the repo if you want mongodb on your vm just write a create-mongo.sh in the scripts and change homestead.rb to run it

I have no idea who you would get homestead to do this

[b3nl]

@ThatTomPerson You got the provisioning script in your project, which everyone uses? I don't understand, how you point invalidates provisioning per project for homestead?

And/But your way, is the way, anybody needs to do. Fork the original homestead, change the homestead.rb, include the forked project ... AND GO. I think, this can be done better ;)

[thattomperson]

I think the best you could get homestead to do is copy the files into you project for you and maybe be a wrapper around vagrant to tell you when you may need to provision again

I would not be opposed to homestead being able to do that but it should be to do this as well as have it's original functionality

homestead init --local

to copy files to you current directory

then if homestead see that there is a Homestead.yaml or Vagrantfile it can go into local mode where is just runs vagrant in the current directory

but if it doesn't find one of those files it runs it in the global version

that would be cool

but now this is just how vagrant works but with some sugar

[micflan]

"just how vagrant works but with some sugar" sounds perfectly fine to me. Homestead was (prior to version 2) essentially a Laravel-ready Vagrant configuration with some helpful wrappers around configuration and cli commands. There's nothing wrong with that; it was very useful.

I've been happily using Purestead on recent projects anyway, so this isn't a massive issue for me (i.e. alternatives are available). I'm just not aware of a good argument for this change to a "global Homestead" in version 2.

It's a lot of extra steps now to get my team on the same environment, and I don't see what's been gained.

[RomainLanz]

You can also still use Homestead 1.

[thattomperson]

@micflan I will have to find a source for this but the goal with Homestead was to have a way to quickly set up a new laravel site in vagrant and making a new box in vagrant is slow so put them all in the same box

I think homestead is good for personal projects and tests eg trying out a new package or trying out a new concept

I think @taylorotwell mentioned this in the lavavel podcast ep 19 but I could be wrong I will listen to it again and find out after work

[thattomperson]

If you want to have a look at how i think local installs of homestead could work have a look at laravel/homestead#173 just an idea discuss

[dbpolito]

I have been using a customized version of homestead after version 2 because of this issue, today this issue came to my attemption and made me figure other people shares this same opinion, so i open sourced my customized version:

https://github.com/dbpolito/firestead

This is basically homestead, no customizations at all, only simplified and per project based.

[deowk]

I think this global homestead is a step backwards, it makes it really hard to commit the dev environment to source control and for other devs to simply vagrant up and get cracking. Plus the provisioning script is running for every homestead up? Each project has it's own provisioning requirements....

[hassankhan]

Have to agree here, it seems a bit backwards. If we could add something similar to what @ThatTomPerson said above (check project folder first, then user folder) then that would be awesome.

[thattomperson]

I tried to talk to Taylor about it and he said that he though Homestead was ok as it is so if we want a feature like this we will have to fork but there is already projects around that do this eg purestead and firestead

I also don't think another homestead fork is a good idea

[hassankhan]

Sucks to hear that :disappointed:

[b3nl]

so, no original homestead in bigger teams with multiple homestead projects for me ... -1

[dbpolito]

I feel bad about this too, but there is no way to please everyone... I don't know if the majority liked this new way, but seems to, as it's simpler... That's why forks exists, someone doesn't like the direction of the main project and fork and customize.

We have two good alternatives, as @ThatTomPerson pointed, purestead and firestead, i haven't tested purestead but seems pretty good to me.

[rossedman]

:+1: I agree with many of the opinions stated in this thread. I love Homestead. I think it has been a great project but with Homestead 2, the added /.homestead directory has caused more problems than solutions for me. I don't really like having Homestead in 2 different directories either. I have started opting for other solutions but would prefer to stick with Homestead if possible.

[ArjanSchouten]

ping @GrahamCampbell this is already achieved so probably you can close this.

[GrahamCampbell]

Thanks @ArjanSchouten.