Extend continuous integration testing matrix

[jGaboardi]

The PR addresses #135.

• adds Python 3.{7,8,9} and macOS & Windows to the testing matrix
• drops support for 3.5 from setup.py
  • seems rtree is no good for Python 3.5

[ronnie-llamado]

@jGaboardi Looks good. While you're in there updating it, do you have any take on a setup.py vs setup.cfg?

[jGaboardi]

@jGaboardi Looks good. While you're in there updating it, do you have any take on a setup.py vs setup.cfg?

I have never used a setup.cfg file myself (actually never even seen one). It appears to be useful for passing in command line args? I'm not sure about the need or usefulness of having one for this project. Is there a case you have in mind for using/needing a setup.cfg?

[ronnie-llamado]

I have never used a setup.cfg file myself (actually never even seen one). It appears to be useful for passing in command line args? I'm not sure about the need or usefulness of having one for this project. Is there a case you have in mind for using/needing a setup.cfg?

PyPA suggests using setup.cfg in most cases since it's static metadata compared to setup.py's dynamic metadata (Packaging Python Projects).

I think you're right though - the implications on this project are minimal. The one added benefit for this project would be configurations for tools like pytest or flake8 would be also be contained in setup.cfg.

[jGaboardi]

I have never used a setup.cfg file myself (actually never even seen one). It appears to be useful for passing in command line args? I'm not sure about the need or usefulness of having one for this project. Is there a case you have in mind for using/needing a setup.cfg?

PyPA suggests using setup.cfg in most cases since it's static metadata compared to setup.py's dynamic metadata (Packaging Python Projects).

I think you're right though - the implications on this project are minimal. The one added benefit for this project would be configurations for tools like pytest or flake8 would be also be contained in setup.cfg.

Indeed very interesting and elegant. What I can see as a pain point here is that setup.py extracts the version from cenpy.__init__.py. Not sure on how to accomplish this within setup.cfg. Also, where are requirements stipulated in setup.cfg files?

[ronnie-llamado]

I have never used a setup.cfg file myself (actually never even seen one). It appears to be useful for passing in command line args? I'm not sure about the need or usefulness of having one for this project. Is there a case you have in mind for using/needing a setup.cfg?

PyPA suggests using setup.cfg in most cases since it's static metadata compared to setup.py's dynamic metadata (Packaging Python Projects).
I think you're right though - the implications on this project are minimal. The one added benefit for this project would be configurations for tools like pytest or flake8 would be also be contained in setup.cfg.

Indeed very interesting and elegant. What I can see as a pain point here is that setup.py extracts the version from cenpy.__init__.py. Not sure on how to accomplish this within setup.cfg. Also, where are requirements stipulated in setup.cfg files?

I think this setuptools documentation shows a better example of setup.cfg.

For the version, one can use the attr directive (very snazzy);

[metadata]
...
version = attr: cenpy.__version__

For the requirements, it would be relisted under install_requires (not so snazzy):

[options]
...
install_requires =
    requests
    ...
    geopandas

[jGaboardi]

[metadata]
...
version = attr: cenpy.__version__

I like this way of specifying version very much.

[options]
...
install_requires =
    requests
    ...
    geopandas

Not a huge fan manually listing out the requirements though.

Let's leave the decision up to @ljwolf. Also, it might be good to have that in a separate PR. It is a relatively minor thing, but a break from the norm since cenpy's inception.

[jGaboardi]

I'll go ahead and merge this. Please revert if I am jumping the gun.