Migrating from setup.py to pyproject.toml

[sammytheindi]

Is your feature request related to a problem? Please describe.
The current use of setup.py for project configuration is becoming outdated and less aligned with modern Python packaging standards. This can lead to potential issues with build isolation, tool interoperability, and future compatibility. Additionally, the imperative nature of setup.py can make it more prone to errors and harder to maintain compared to newer declarative formats.

Describe the solution you'd like
I propose migrating from setup.py to pyproject.toml for project configuration. This would involve:

1. Creating a pyproject.toml file that includes all the configuration currently in setup.py.
2. Removing the setup.py file.
3. Updating any build processes or CI/CD pipelines to work with the new configuration.
4. Ensuring all necessary build dependencies are specified in the pyproject.toml file.

Describe alternatives you've considered

• Keeping setup.py but modernizing it to use setup.cfg for most configuration, with setup.py only for dynamic configuration.
• Using a tool like Poetry for dependency management and packaging, which would replace setup.py entirely with its own workflow.

Additional context
Adopting pyproject.toml aligns with PEP 518 and PEP 621, which are pushing the Python ecosystem towards more standardized and interoperable project configurations. This change would make JobFunnel more compatible with modern Python tooling and packaging practices.

Many popular projects and tools in the Python ecosystem are moving in this direction, including pip, which now prefers pyproject.toml for build information.

This change would also make it easier for contributors to understand and modify the project configuration, as pyproject.toml is generally more readable and less prone to errors than setup.py.

[sammytheindi]

I have updated the configuration settings on the branch 172-migrating-from.... I have also added a readme section for new developers to make it easier to contribute to the project.

To maintain style consistency, I am thinking of adding in isort and flake8 going forward. This adds a little overhead, but will ensure that the codebase remains consistent. I am not certain about whether the changes I have made will effect anything downstream (CI, etc.). I don't think so, but would be happy to make changes if that is the case.

Any other thoughts/additions?

[PaulMcInnis]

Love it, I think potentially the style of typing here is also out of date - but it’s a pain to update and probably a separate task.