One thing I find myself needing again and again is a way to have different sections of a make file enabled based on command line options.

As an example, it would be great if we could pass a 

--env=dev

to make and then it will execute a section of the make file that surrounded with an environment spec. For my dev example, it would specify things like the devel module (and other modules I don't want installed on a production server) it can also do things like specify the read/write git repo urls to projects so that when I am building for dev I can have a vast majority of my modules actual git checkouts for generating patches or committing directly to (if I have commit rights)

if I specify 

--env=prod

The sections specified as dev env would not get executed, but my prod section would execute that would include things like a Feature with Strongarm'd variables for all of our clients production API keys or prod Solr urls, maybe an Acquia connector module or something that is only specific to a prod deployment.

I have been meaning to write this for at least a year now, but I figured I would throw it out here so that in case someone else has the need we can collaborate on writing a patch or something.

Anyway, this would be incredibly sweet.

Comments

febbraro’s picture

febbraro commented
Title: Allow for different environment regions in a make file » Allow for different environments in a make file

It need not even be a region like

env[dev] = {
   project[devel] = 2.0
}

it could possibly be a prefix

dev[project][devel] = 2.0
prod[project][api_keys] = 2.0

or

env[dev][project][devel] = 2.0
env[prod][project][api_keys] = 2.0
walkah’s picture

walkah commented

See, if we used proper .ini file syntax, we could get sections like:

[dev]
project[foo][version] = 1.x-dev

[prod]
project[foo][version] = 1.0

But, no matter the syntax, it'd be great to list dev-only dependencies. (Same goes for .info files for install profiles).

febbraro’s picture

febbraro commented

That's just crazy talk....or is it? Any chance we can move make files to a .ini syntax?

moshe weitzman’s picture

moshe weitzman commented

Seems kinda exotic to me. All sites could have same codebase, and environment specifics could go into the install_profile logic. You have PHP access there, anyway.

greg.1.anderson’s picture

greg.1.anderson commented

I think this feature has merit, but I don't like any of the syntax examples provided in #1. I think I would prefer to tag each project with the environment or environments that it should appear in.

For example:

projects[devel][type] = "module"
projects[devel][env] = "dev,testing"
projects[api_keys][type] = "module'
projects[api_keys][env] = "prod"

It might also be useful to bundle dev and prod makefiles up separately (e.g. a my_devel_env.make that includes devel, coder, and anything else you want in a dev environment). For this sort of "naked" environment makefiles, maybe specifying addtional makefiles on the commandline would be effective.

greg.1.anderson’s picture

greg.1.anderson commented

+1 for #4.

febbraro’s picture

febbraro commented

@moshe We are very often in a scenario where we are working on a site that already exists and we are just building the "code" to go on top of an existing database. In that scenario the install profile is not executed after the make is run, so this seems something best done as part of make. We don't put a full/built site into version control, just the profile which contains the make and a modules/themes directory for custom stuff.

febbraro’s picture

febbraro commented

@greg the problem with dev/prod separate make files is that they are not orthogonal (if I used that word correctly) it is not like the dev version has things not present in the prod one. They often times have the same things but variations. Like the OP in dev I would have checkouts and in prod it would be downloads from d.o releases.

greg.1.anderson’s picture

greg.1.anderson commented

Regarding git versus wget, I think that is actually a separate issue / feature request: there should be a way from the cli to override the download type settings -- for example, set up your makefile to pull from git, and use a cli option to force the download type to wget from d.o. for all projects that exist on d.o. (c.f. existing flag --working-copy).

Having multiple dev / prod settings for every project seems messy to me; it makes the makefiles harder to read. Keeping the basic syntax of projects[foo]... is important.

Adding sections per #2 would be a big change, and again, sections only help if your common projects are more or less uniform between dev and prod.

moshe weitzman’s picture

moshe weitzman commented

Thanks for the use case in #7. In this use case, it seems fine for the makefile to always include the modules that are developer-only. After making the codebase, the dev would only have to enable these modules.

Agree with Greg's #9 about the strategy of overriding download method via command line option.

igor.ro’s picture

igor.ro commented
Version: » 8.x-6.x-dev

For me this will break code consistency because there is no way to be sure that bugs fixed in dev environment would not back in prod env.
Sure if you use different source for the same module in dev and prod env.
Better to use recursive make files and git branches for that.

agree with #8
Environments in make file will make it mess.

We do the required things in other way.
1. In git we have such code https://github.com/goruha/drupal_phing
2. We have development modules in code base allways.
3. To remake codebase we use $ phing remake
4. To install modules us module drush_migrate (drake)
5. Also use environment module to enable/disable developer modules like devel.

Probably it would be better if you change your workflow.

greg.1.anderson’s picture

greg.1.anderson commented
Status: Active » Closed (won't fix)
Issue tags: +Needs migration

This issue was marked closed (won't fix) because Drush has moved to Github.

If this feature is still desired, you may copy it to our Github project. For best results, create a Pull Request that has been updated for the master branch. Post a link here to the PR, and please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.