Define the dependencies in only one place using setup.py

[ue-sho]

This PR (#66) introduced pipenv, but the documentation and GitHub Actions use venv, so developers are confused as to which to use.
Therefore, I modified it to use pipenv.
In addition, the name of the GitHub Actions was changed from tester.yml to ci.yml because I will introduce Ruff to check lint and format (#75).
After this PR is merged, I intend to create a PR that will introduce Ruff.

[pchoisel]

Hi, thanks for your contribution !
To be fair, I'm not fond of pipenv. Because of it, we now have a third place where we have to define the dependencies: setup.py (for Python3.6 compat), pyproject.toml (for Python3.12 support) and Pipfile.
This is likely to create problems when we want to change the dependencies...
Apart from being a bit easier to easier to use than venv, is there really a good reason to use this ?
(I know I should have asked that question in #66...)
@smjoshiatglobus Do you have an opinion on this ?

Apart from that, the rest of you contributions (renaming tester.yaml to ci.yaml and adding cache in the CI) are good for me.

[smjoshiatglobus]

Hi, thanks for your contribution ! To be fair, I'm not fond of pipenv. Because of it, we now have a third place where we have to define the dependencies: setup.py (for Python3.6 compat), pyproject.toml (for Python3.12 support) and Pipfile. This is likely to create problems when we want to change the dependencies... Apart from being a bit easier to easier to use than venv, is there really a good reason to use this ? (I know I should have asked that question in #66...) @smjoshiatglobus Do you have an opinion on this ?

Apart from that, the rest of you contributions (renaming tester.yaml to ci.yaml and adding cache in the CI) are good for me.

I agree that defining dependencies in three places is not a good idea. Duplicating dependencies is worse! To be fair to pipenv, the dependencies in pipenv are optional and meant for developers of this package while those in pyproject.toml are for others who only import the package. I switched to pyproject.toml after observing that pydicom had switched to it. When I created PR #66, the supported version of python was >= 3.7. That has moved to 3.6 now.

It makes sense to define the dependencies in only one place. Since setup.py will work for all versions of python, I support dropping both pyproject.toml and Pipfile and sticking to only setup.py.

[ue-sho]

Given that setup.py supports all versions of Python you are dealing with, I too think it would be wise to consolidate dependency management there.
I am going to change the installation to using setup.py.

[ue-sho]

On second thought, I think it would be better to use pyproject.toml.
The pyproject.toml file provides a more modern and simplified management of the build system instead of using setup.py.

Since setuptools supports pyproject.toml, I think it should also work with python 3.6.
pypa/setuptools#2970

So I will try to find a way to implement it using pyproject.toml.

[ue-sho]

So I will try to find a way to implement it using pyproject.toml.

When Python version is 3.6, the installation of editable mode (pip install -e .[dev]) fails due to low version of setuptools.
Therefore, I decided to define it in setup.py.

@pchoisel @smjoshiatglobus
Please review when you have time.

[ue-sho]

I have confirmed that CI works fine using act.

[smjoshiatglobus]

One minor comment on a dead link in setup.py. Otherwise LGTM.

[smjoshiatglobus]

Suggested change

	# https://packaging.python.org/en/latest/requirements.html
	# https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/

The link on line 45 is now dead.

[ue-sho]

I fixed it.

[smjoshiatglobus]

LGTM

[ue-sho]

@pchoisel
If you merge this PR, I will immediately create a PR that will check the format and lint of the code by ruff.

[pchoisel]

Thank you !