Better packaging

[ewjoachim]

The current PyPI page is lacking a lot of very important things, including the long description, and a link to the source code. It doesn't say that this is the official docusign python client.

I'd be glad to make a PR for this, but I wanted to consult with you first.

[LarryKlugerDS]

Hi @ewjoachim,

Thank you for your comment. We're working on the next version of the SDK so we'll also update the PyPI page at that time.

Can you recommend one or two PyPI pages of similar SDKs that you feel do the best job?

Thanks, Larry

[ewjoachim]

What you'd be looking for IMHO:

• long-decription from README.md (https://pypi.org/project/vault-cli/ / https://github.com/peopledoc/vault-cli/blob/master/setup.cfg#L8-L9 )
• Homepage URL and project urls pointing to all the relevant places (docusign docs, this github repo) (https://pypi.org/project/setuptools/ / https://github.com/pypa/setuptools/blob/master/setup.py#L102-L104 )
• Badges (https://shields.io/ as seen on https://github.com/dropbox/dropbox-sdk-python for example)
• It's your choice, but I'd say it's a lot cleaner to have everything in setup.cfg and nothing in setup.py (https://github.com/peopledoc/raincoat/blob/master/setup.py / https://github.com/peopledoc/raincoat/blob/master/setup.cfg)
• It's your choice, but I'd say it's nice to have all your requirements in your setup.cfg, including test / lint, using extras. This way you can pip install -e .[tests] for example. Tox plays very nice with that. See https://github.com/peopledoc/vault-cli for an example of that.
• Add classifiers, especially regarding supported python version (see... All the examples above :D )
• While you're at it, feel free to add a CONTRIBUTING.md, and explain what kind of contributions you're expecting from the community :)

[ewjoachim]

Oh BTW, your toxfile is not specifying which python3 subversion it's testing so it's kind of ambiguous. It would feel better to explicitely decide what you support and what you don't.

Also, having done that, it would be nice that Travis would use tox instead of being a parallel entrypoint.

And finally, the paragraph regarding the Pythonpath in the readme makes me really inconfortable. If you already know about these things, you don't need a documentation, and if you don't, in my humblest opinion, it's a really dangerous to play with pythonpath like this, you want to use a virtualenv or pipenv/poetry, but definitely not this. Same thing when you're suggesting doing a sudo pip install, I fear it's the easiest way to end up with a system in a funny state.

https://xkcd.com/1987/

Once again, I'd be glad to make you a PR and fix all those things :)

[LarryKlugerDS]

Thank you @ewjoachim. I have forwarded your offer to our engineering group and am waiting to hear back from them. We appreciate your help and your offer of proposing a PR.

[ewjoachim]

Anything new on this ? #29 could be dealt with at the same time.

[Mariatta]

Just bumping this. I came across the PyPI page and also wished that it has more information than what's currently there.

It would be great if the long_description field could be populated with the readme. Additionally, it would be great if the url field is not empty. It could just point to this repo's url.

Here's the documentation on making a PyPI friendly readme: https://packaging.python.org/guides/making-a-pypi-friendly-readme/

I also agree that for installation instructions could be improved. Suggesting the use of virtual environment is common practice nowadays.

Thanks.