Moved the metadata into setup.cfg.

[KOLANICH]

• ignored some stuff

[alexmojaki]

Hi, can you explain what the goal/purpose of these PRs is?

What would be the procedure to release a new version of a package?

Can you fix the travis build?

[KOLANICH]

Hi, can you explain what the goal/purpose of these PRs is?

1. store the metadata as data, not as code. This will allow to phase out metadata stored as code in future. It will also make it more available for tools.
2. get the version from the git tag automatically.

What would be the procedure to release a new version of a package?

1. make a new git tag v<version>
2. python3 -m pep517.build .
3. twine upload ./dist/*.whl

[alexmojaki]

Does this have something to do with IPython?

[KOLANICH]

Yes, I have installed a new version of ipython from git and noticed a new dependency; I have looked into it and its dependencies and disliked the way they are packaged, so I have sent PRs to them. Fortunately with the help of setuptools_py2cfg converting the metadata was pretty easy.

[alexmojaki]

Please add pep517 as a test dependency to make packaging easier, and make a shell script out of these steps you just gave.

[KOLANICH]

make a shell script out of these steps you just gave.

It is not trivial to read the previous tag describing a version, and increment it in bash. And versions, if they are SemVers, must be incremented by a human.

Please add pep517 as a test dependency

Added to extras and not added to test_requires because it is not needed for testing. In fact it is not really very needed at all, python3 ./setup.py bdist_wheel still works fine, pep517 is just a build system independent interface recently introduced. Shiny new shit it is. We use it on travis only to make sure that the package is compatible to it (pip uses it if it encounters pyproject.toml with build backend assigned).

[alexmojaki]

The version can be an argument which I type in manually. I just don't want to have to remember and manually enter three commands.

[alexmojaki]

Anyway, thanks for your help and for teaching me new things. Before I merge anything, can you also make the same changes in executing and pure_eval?

[alexmojaki]

Next time I want to release a change, I will test this branch out in practice. I'm not keen to merge into master a new set of tools that I'm completely unfamiliar with.

[alexmojaki]

OK, I tried using this in practice and ran into a couple of problems.

Firstly, no matter how I run the script, the argument detection fails and it tells me to provide a version:

$ ./make_release.sh 0.0.7
+ '[x]'
./make_release.sh: line 4: [x]: command not found
+ echo './make_release.sh <major>.<minor>.<patch>'
./make_release.sh <major>.<minor>.<patch>
+ exit 1

Secondly, how am I meant to work with version.py in practice? Someone should be able to clone this repo and then run tests, but they hit an import error because version.py doesn't exist. They shouldn't have to build the project to work with it.

[alexmojaki]

OK, I fixed the problems and merged in #7.

[alexmojaki]

Thank you for this contribution @KOLANICH, I've learned some new stuff!

Can you similarly update your PRs for executing and pure_eval?