Cannot run setup.py if setup.py is not in sys.path

[mrginglymus]

setup.py can only currently be run if the jose can be imported. It is presumably assumed that the source root will be somewhere near the top of sys.path but this is not always the case.

There are, therefore, two failure modes possible. If python-jose is not already installed, setup.py cannot be run at all. If python-jose is installed, then the version from the installed copy is used to generate the version for setup.py.

Switching to using setup.cfg:

[metadata]
version = attr: jose.__version__

allows setup.py to be run even if the source root is not on the path.

[blag]

According to https://setuptools.readthedocs.io/en/latest/setuptools.html#metadata:

Note: The aliases given below are supported for compatibility reasons, but their use is not advised.

Key	Aliases	Type	Minimum Version	Notes
...	...	...	...	...
version		attr:, file:, str	39.2.0	1.

Notes: 1. The version file attribute has only been supported since 39.2.0.

[blag]

Can you give me an example of a setup.py command that you cannot run without this PR?

[mrginglymus]

Any setup command will fail to run. Our particular environment is a bit convoluted (we use the embeddable windows distribution with a locked down _.pth file), but you can easily reproduce the issue in a normal environment by running python in isolated mode, e.g.

$py -3.7 -I setup.py egg_info
Traceback (most recent call last):
  File "setup.py", line 6, in <module>
    import jose
ModuleNotFoundError: No module named 'jose'

[zejn]

Thanks, @mrginglymus, that helped a lot. I can confirm and reproduce the issue.
The -I switch does not add the current directory to PYTHONPATH so it can't find jose.

Of the two failure modes the second one is far worse since you get old version but new code.

One way to solve this is your recommendation. Not sure if depending on setuptools>=39.2.0 has side effects.

[mrginglymus]

We only encountered this problem when we switched from 3.0.1 to 3.1.0, because wheels haven't (yet?) been published to pypi. Publishing wheels would make this problem go away for us for now :)

[blag]

Sorry I didn't realize that I needed to publish wheels to PyPI for this project (3.1.0 was my first release).

I've uploaded a wheel for 3.1.0 to PyPI - that should get this working for you.

Version 39.2.0 of setuptools was released on May 19th, 2018 (a year and a half ago at this point), so I don't mind depending on that version or greater. However, I would need a very good reason for doing something that is explicitly recommended against by the setuptools developers themselves.

Do we need a way to workaround this aside from uploading/using wheels? If not, I'll just look into codifying the release process by whipping up some Invoke tasks to handle it for me.

[zejn]

Python-jose is not a binary wheel, so if there's a wheel available, that should cover most of the users.

That being said, I don't think putting new code under older version (the first failure mode) is ever acceptable.

I think you are misreading the setuptools documentation, @blag. The setuptools documentation says that aliases are not advised, not the key itself. "Version" key has no aliases specified.

Simplest solution looks to be to add "setuptools>=39.2.0" to setup_requires.

[blag]

Oh, derp. I think you're right that I'm misreading the docs. I'm happy with putting version in setup.cfg and adding setuptools>=39.2.0 to setup_requires in setup.py.

@mrginglymus Do you mind turning this into a pull request?

[mrginglymus]

Sure! Might be an after Christmas job at this point though :)