There are a couple of scenarios where having multiple engineer sites within a single config might come in handy. First, in order to demonstrate the themes Engineer provides - you could have a single engineer config that built out a version of a site with each theme. I actually need this for the Engineer 'marketing' site (still a work in progress).
Another use-case is a team or organization with several members. They might have an engineer site at their top level domain with sub-sites for each team member or project they're working on (see also this comment from @jcrubino).
In both of these cases, this is possible today with a batch file that runs several engineer builds. Each build config file would output to a subdirectory within the first site's output directory. For example, consider a site with two engineer sites underneath it. The batch file might look like this:
Assuming top_level_site.yaml set its output directory to output\, then tyler_blog.yaml might set the output directory to output\blogs\tyler\ and patrick_blog.yaml might set its output directory to output\blogs\patrick\. By building things sequentially, each site would wind up in the right spot. The subsites would also need to set their HOME_URL settings appropriately.
Anyway, there are a couple of drawbacks to this. First, because the build processes are separate, the build of the first site will delete all the output of the second sites, so some of the speed engineer gets from reusing existing content will be lost. Second, it's somewhat complicated to configure and maintain.
It seems like there are a couple of options. First, documenting the above as an available, albeit complicated and less than ideal, option would be good. I filed issue #53 on that. Longer term, I can imagine making this sort of thing simpler with a new command, say multibuild that takes a slightly different config file as input, then performs multiple builds. Basically, I could wrap the 'batch file' concept above in an actual command and make some optimizations in the code to address the performance problems the batch file introduces. This should make it easier to get up and running with a multi-site config.
I really like this idea, and could make use of it on the Engineer 'marketing' site, but the batch file seems like an acceptable workaround for now, so I'm putting this on the back burner for the time being.
There are a couple of scenarios where having multiple engineer sites within a single config might come in handy. First, in order to demonstrate the themes Engineer provides - you could have a single engineer config that built out a version of a site with each theme. I actually need this for the Engineer 'marketing' site (still a work in progress).
Another use-case is a team or organization with several members. They might have an engineer site at their top level domain with sub-sites for each team member or project they're working on (see also this comment from @jcrubino).
In both of these cases, this is possible today with a batch file that runs several engineer builds. Each build config file would output to a subdirectory within the first site's output directory. For example, consider a site with two engineer sites underneath it. The batch file might look like this:
Assuming
top_level_site.yamlset its output directory tooutput\, thentyler_blog.yamlmight set the output directory tooutput\blogs\tyler\andpatrick_blog.yamlmight set its output directory tooutput\blogs\patrick\. By building things sequentially, each site would wind up in the right spot. The subsites would also need to set their HOME_URL settings appropriately.Anyway, there are a couple of drawbacks to this. First, because the build processes are separate, the build of the first site will delete all the output of the second sites, so some of the speed engineer gets from reusing existing content will be lost. Second, it's somewhat complicated to configure and maintain.
It seems like there are a couple of options. First, documenting the above as an available, albeit complicated and less than ideal, option would be good. I filed issue #53 on that. Longer term, I can imagine making this sort of thing simpler with a new command, say
multibuildthat takes a slightly different config file as input, then performs multiple builds. Basically, I could wrap the 'batch file' concept above in an actual command and make some optimizations in the code to address the performance problems the batch file introduces. This should make it easier to get up and running with a multi-site config.I really like this idea, and could make use of it on the Engineer 'marketing' site, but the batch file seems like an acceptable workaround for now, so I'm putting this on the back burner for the time being.