--env option not working?

[archfrog]

I just tried this command:

./artisan iseed --env=.env.SHIP table

The .env.SHIP file contains the production values; I was trying to inverse seed my production data into my development environment. The result was useless as no data were imported. Luckily, I have everything under Git, so I could quickly restore the original seed file.

Then I tried adding a new database connection in config/database.php under the name of public, using the same information found in the .env.SHIP file, and ran the command:

./artisan iseed --database=public table

This time everything worked as expected.

The question is if the --env option works at all or if it should be removed? Or am I misunderstanding its usage?

[tihomiro]

Hey @archfrog , you got me for a minute, wondering why --env option doesn't work, only to realize that we don't have --env option at all. A list of all options is accurate in our README.md, and you can view the actual parameters that are being parsed in https://github.com/orangehill/iseed/blob/master/src/Orangehill/Iseed/IseedCommand.php file.

I do agree that this is a valid feature request, though, so I'll mark it as such. Hope to have it implemented in the next dev iteration.

Thanks!

[archfrog]

Haha, that explains a lot :-)

Well, then the help text for the iseed command is wrong. If I run ./artisan help iseed, I get this output:

Usage:
  iseed [options] [--] <tables>

Arguments:
  tables                       comma separated string of table names

Options:
      --clean                  clean iseed section
      --force                  force overwrite of all existing seed classes
      --database[=DATABASE]    database connection [default: "mysql"]
      --max[=MAX]              max number of rows
      --exclude[=EXCLUDE]      exclude columns
      --prerun[=PRERUN]        prerun event name
      --postrun[=POSTRUN]      postrun event name
      --dumpauto[=DUMPAUTO]    run composer dump-autoload [default: true]
      --noindex                no indexing in the seed
      --orderby[=ORDERBY]      orderby desc by column
      --direction[=DIRECTION]  orderby direction
  -h, --help                   Display this help message
  -q, --quiet                  Do not output any message
  -V, --version                Display this application version
      --ansi                   Force ANSI output
      --no-ansi                Disable ANSI output
  -n, --no-interaction         Do not ask any interactive question
      --env[=ENV]              The environment the command should run under
  -v|vv|vvv, --verbose         Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Help:
  Generate seed file from table

So the online help says there is an --env option as the 2nd last option in the help text. That's where I got the idea to use it from :-)

I'm no Laravel expert, but I'm not sure you can use a different environment at all. If you can, it would definitely be great as I've temporarily added a new database connection to config/database.php.

[tihomiro]

Well, that's the artisan default param, but we're not using it even though you've passed it through. We should be able to, stay tuned :)

[archfrog]

I realized that the --env option probably was added by artisan itself. So I tried using this command:

./artisan --env=SHIP iseed table

That worked as expected. The caveat is that you must use the naming convention .env.XXX and specify only XXX as the argument to the --env option.

As far as I can tell, you don't need to change anything except perhaps the documentation for iseed.

[tihomiro]

Oh, thanks for the info. We'll update the docs.

[archfrog]

Thanks!

[archfrog]

I'm baffled...

The above used to work fine. I could iseed from my production server using a simple --env=SHIP option before the iseed command (the --env option is handled by Artisan itself).

Now, however, I just get a bunch of bogus seed files and no error whatsoever. I discovered this because my development site just kept saying Oops, ... and I couldn't access it: All tables where empty after having been seeded with fresh seed files.

I know for sure that my production server's database is accessible from the outside as I regularly use HeidiSQL to inspect and modify data in it. Also, the .env.SHIP file that I use is used on the production server itself.

Somehow, somewhere, somebody has broken the use of the artisan --env=xxx option during the past two or three months (its been a while since I did an inverse seed the last time).

I'll spend some time to try to track down the problem, but it comes at a very inconvenient time :-)

[archfrog]

Ah, it was a case of the THOU SHALT CLEAR THE CONFIG CACHE!...

This problem is solved simply by issuing the command: php artisan config:clear before iseeding.

I hope this helps someone, somewhere at some point in time :-)