Added 'create' and '--export SHELL' to the cli

[jadutter]

• Added support for specifying when to add 'export' to the dot file
• Added support for creating dot files from the cli

[coveralls]

Coverage increased (+0.5%) to 90.353% when pulling 5a51bde on jadutter:master into 92ec3b2 on theskumar:master.

[jadutter]

...I'm not sure what else I need to do to help contribute...
I see the coveralls report, but I don't understand how I use this information to increase coverage...

[bbc2]

Thank you for submitting this pull request. I like the idea of being able to make set add the export directive to the .env, since that's a supported feature in the parser, but I think the following additions are not worth it for this project (a bit overkill or too complex):

• Support for different shells.
• Validating the file extension.

So what about just adding a bare --export option to set?

About the create command: I'm not sure it's useful since set should implicitly create the file if it doesn't exist, but maybe I'm missing a useful use case?

[jadutter]

I tried creating the file through set and it didn't work for me. I only added the create since it seemed weird that I there wasn't a means in the cli to do it. Probably just user error, but I'll double check.

Extension checking only matters if other shells matter, and I was uncertain how many people use it in other shells where export wasn't valid.

I started to add batch (Windows) as a shell option, but the parser failed to read it, and I decided to keep it small and see what other people thought.

[theskumar]

Hi @jadutter , thanks for sending the PR!

The set not creating a new file was intentional as I didn't really want any user to be confused where the file is made and the file location was supposed to be conscious decision by the user.

That said, the project has evolved and .env in the root of the folder seem to be the default now and the api's of this project have envolved to treat it like that.

I would prefer to have set command, create a new .env in the current folder if it's not present.

I'm also little concerned around the use-case vs the technical debt this project is going take because of adding export feature for each type of shell.

[jadutter]

I'm also little concerned around the use-case vs the technical debt this project is going take because of adding export feature for each type of shell.

I'm not attached to the idea of different shells. I'm just trying to help make it useful to as many people as possible.

Shall I:

• Remove the multiple shell support
• Remove the create option
• Change set to create the file if it does not exist
  And resubmit the PR?

[bbc2]

I think that would be great.

[jadutter]

I believe I've made the necessary changes. Please let me know if there's any other changes I can make.

[bbc2]

Looks good overall! Just a few minor comments.

Could you add a simple test case for something simple like set --export a b that checks that the env file then contains export a=b? It might make Coveralls happy but don't worry if it doesn't.

Also, it looks like the CI doesn't run linters and tests anymore (@theskumar any idea why that could be? I don't see Python-dotenv in Travis CI anymore). Could you try running flake8 or tox -e lint locally to check for warnings?

[jadutter]

Let me know if I should change it so that it does not automatically add the file extension.

[bbc2]

Let me know if I should change it so that it does not automatically add the file extension.

Yes please. I would rather have the user include the extension themselves if they want it.

[bbc2]

I reverted the test, updated the changelog, and squashed the commits. Unfortunately, I pushed the wrong commit to your branch, which closed the PR and prevented me from pushing anything else to it. That's the second time this happens to me; apparently I can't get it right.

Anyway, I created a new PR (#275) with that commit and merged it. Thank you for your contribution! I'll release a new version after I have figured out what's wrong with Travis CI.