Fix test_console failure finding pipdeptree in other environments

[xiacunshun]

When we are using pytest in packaging process, we may not get the /usr/bin/pipdeptree as we need. So, let's use the PATH env to get the binary instead.

fix: #348

[gaborbernat]

I don't like this, if someone's has another pipdeptree on an earlier path we'd wrongfully accept it.

[kemzeb]

Since it looks like this test exists to ensure that our pipdeptree console script exists, I believe an alternative way to test this without relying on a file path is to utilize importlib.metdata.Distribution.entry_points(). We can do something like the following:

d = distribution("pipdeptree")
our_entry_points = d.entry_points
assert len(our_entry_points) == 1
pipdeptree_entry_point = our_entry_points[0]
pipdeptree_module = pipdeptree_entry_point.load()
return_code = pipdeptree_module()
assert return_code == 0

The load() call will return the module associated to the entry point (so pipdeptree.__main__) and we can execute it from there.

[xiacunshun]

Emm, sorry, I retry this test in packaging, but looks failed also?

____________________________________________________ test_console ____________________________________________________

    def test_console() -> None:
        d = Distribution.from_name("pipdeptree")
        our_entry_points = d.entry_points
>       assert len(our_entry_points) == 1
E       assert 0 == 1
E        +  where 0 = len([])

[kemzeb]

Emm, sorry, I retry this test in packaging, but looks failed also?

____________________________________________________ test_console ____________________________________________________

    def test_console() -> None:
        d = Distribution.from_name("pipdeptree")
        our_entry_points = d.entry_points
>       assert len(our_entry_points) == 1
E       assert 0 == 1
E        +  where 0 = len([])

That's weird. It's able to find pipdeptree's metadata but can't find its console scripts? Can you provide the steps you ran before running the test

[xiacunshun]

I think I figure it out....
After the step "%generate_buildrequires" in spec file, a dist-info is created in source directory.

<mock-chroot> sh-5.2# ls pipdeptree-2.18.0/
LICENSE  README.md  pipdeptree-2.18.0.dist-info  pyproject.toml  src  tests  tox.ini

But it only has a METADATA under it.

<mock-chroot> sh-5.2# ls pipdeptree-2.18.0/pipdeptree-2.18.0.dist-info/
METADATA

When we run pytest, current directory is added to sys.path which cause distribution can find the fake dist-info and recognizes it as the pipdeptree.

[xiacunshun]

I am not sure why they do this, but it looks affect our testcases.
see https://src.fedoraproject.org/rpms/python-pipdeptree/blob/rawhide/f/python-pipdeptree.spec

[xiacunshun]

Emm, sorry, I retry this test in packaging, but looks failed also?

____________________________________________________ test_console ____________________________________________________

    def test_console() -> None:
        d = Distribution.from_name("pipdeptree")
        our_entry_points = d.entry_points
>       assert len(our_entry_points) == 1
E       assert 0 == 1
E        +  where 0 = len([])

That's weird. It's able to find pipdeptree's metadata but can't find its console scripts? Can you provide the steps you ran before running the test

I download their src.rpm(here), uncompress it, replace the sources with our new code and then rpmbuild -ba ~/rpmbuild/SPECS/python-pipdeptree.spec.
(There are also some steps to deal with dependencies.)

[kemzeb]

So from reading the Fedora spec dealing with Python packages and this Python spec, it looks like packaging tools aren't required to create an entry_points.txt metadata file if they don't want to. But they must at least generate a METADATA file.

I'm not familiar with the packaging process, let alone with Fedora, but this does reflect your outputs since we only see the METADATA file (although the Fedora docs explain that the source and the metadata should be installed in "%{python3_sitelib} or %{python3_sitearch}" rather than within the source directory?).

I'm unsure why it is not required for entry_points.txt to be generated when there are console scripts that exist, but because of this testing by using the importlib API here may only work for package installers that do generate entry_points.txt if possible (e.g. pip).

[kemzeb]

There looks to be a pytest plugin just for testing console scripts, and from looking at the source it seems that it will either:

• Load the script using importlib.metadata.entry_points() (see here)
• Look for the script in either PATH or the cwd if it doesn't find the entry point when using importlib.metadata (see here)

[xiacunshun]

There looks to be a pytest plugin just for testing console scripts, and from looking at the source it seems that it will either:

• Load the script using importlib.metadata.entry_points() (see here)
• Look for the script in either PATH or the cwd if it doesn't find the entry point when using importlib.metadata (see here)

This approach worked and looks solve the problem in packaging!
I retried, and console test passed.

[kemzeb]

Will release 2.18.1 after merging this