provide -m entry points about diff_cover HOT 7 CLOSED

https://pypi.org/project/diff-cover/2.0.0/ released

from diff_cover.

I think this should be rather doable. I honestly thought it was already possible with python -m diff_cover.tool but I just realized why that does not work.

Ill see if I can find some time to look into this in the next few days.

But can you talk to me a bit more about what you mean by "access the command without mangling with the path"?

from diff_cover.

Took a stab at this here #98

Turned out to be harder than it should have been. The problem was diff-cover and diff-quality shared a main method and relied on the entry point to branch between them. So I had to split the two up.

I prefer them split up anyway. I am going to leave the PR up for a few days to see if anyone is watching and then release it.

After its released and assuming I did not break anything you should be able to run it without relying on the entry points with

python -m diff_cover.diff_cover_tool

and

python -m diff_cover.diff_quality_tool

Though I would love to learn more about your use case. What is the problem with the existing method for running the tools?

from diff_cover.

Multiple reasons:

1. It's about explicit over implicit. When you have multiple pythons installed typing in diff_cover really gives you no clue under what python will be executed. If you do python3.7 -m diff_cover it's more explicit.
2. Especially on Windows (but Unix too applies) it's not recommended/easy to add new entries under the path (such as your python scripts folder). Instead one uses the py command that discovers python packages and is able to invoke pythons from under that path. For example py -m diff_cover invokes the default python, py 3.7 -m diff_cover will use python 3.7). Therefore -m is more inclusive.
3. The generated console scripts use the shebang line to bind it to the python to be executed with it. The shebang line is though length limited (128 chars max). Therefore invoking the diff_cover console script fails horribly with a cryptic message (especially on CI-s, such as Jenkins that generates long paths). The -m does not has this drawback, and will always work.

I think your name is kinda long to type, would prefer python -m diff_cover and python -m diff_cover.quality 👍

from diff_cover.

Gotcha, so generally in my workflow im using python virtualenvs. I dont use the default python for much of anything other then creating a virtualenv.

I hear ya on wanting the shorter names. But I wanted consistency between the two tools and the structure of the modules.

I dont actually think anyone is watching PRS to this repo so im gonna go ahead and do a merge/release

from diff_cover.

I hear ya on wanting the shorter names. But I wanted consistency between the two tools and the structure of the modules.

Sounds to me like you're choosing developer convenience over ease of use. Either way, thanks for the fix.

from diff_cover.

I mean maybe. I made a decision for the structure of the project. I could be wrong but my assumptions and experiences are that most users use diff-cover as part of a CI process and are not typing the command in by hand anyway.

And those who do have plenty of options for aliasing to have any UX they want.

from diff_cover.