Where's setup.py gone?

[brobr]

Your Environment

Thank you for taking the time to report an issue.

To more efficiently resolve this issue, we'd like to know some basic information about your system and setup.

1. Your operating system:
   Slackware linux current64 (15.0rc)
2. Version of python you are running:

3. How did you install twine? Did you use your operating system's package manager or pip or something else?
   Install failed via build script (see below)
4. Version of twine you have installed (include complete output of):
   tried to upgrade to version 3.4.2 from 3.2.0
5. Which package repository are you targeting?
   none; just building twine

The Issue

Please describe the issue that you are experiencing.

Using a buildscript based around the command python3 setup.py install. failed:

python3: can't open file '/tmp/SBo/twine-3.4.2/setup.py': [Errno 2] No such file or directory

Steps to Reproduce

If the issue is predictable and consistently reproducible, please list the steps here.

[bhrutledge]

Sorry to hear that you're having trouble. setup.py was removed in #757 (which explains the reasoning).

Are you using python3 setup.py install to install Twine from source? If so, the preferred approach is to use pip to install the package from the current directory:

python3 -m pip install -U .

If you run into trouble there, check your version of pip, and upgrade if necessary:

python3 -m pip --version

python3 -m pip install -U pip

[sigmavirus24]

Other linux distributions now build the wheel in order to install from a source distribution, e.g., Fedora: https://src.fedoraproject.org/rpms/python-twine/blob/51921fdf414394643792d3cf7429b02f64bdce7b/f/python-twine.spec#_65 You can use python -m build instead of pyproject as documented there

[brobr]

Hi, I am not going to argue or delve in all the reasoning why everyone should use pip. Compiling from source is used to generate packages that are to be distributed over a range of computers. This `compile once and install using the system's packaging management` makes it much easier to keep track of what is on a box. (For an administrator to keep track of there's more on a box than python...) Pip, like all other 'packaging systems' linked to a programming tool (say R, Ruby..), enforce all compilation to happen per box. It bypasses the OS-packaging system and because of its dependency tracking and automatic installing what's needed, it is not at all helpful to generate packages to be distributed. What I find astonishing is that python is on the way to bury it's KISS attitude. The line `python3 setup.py install` I grew up with and has been the basis of all simple installs. If one goes to pypi.org and tries to get the right package for one's installation, before one has figured that out (which python version?, what whl?? ) it's easier to download the source and compile. Error messages quickly tell what is missing (or check the requirements.txt in the package for this) and one can get those in and thereby remains in control of what distribution packages one is making and thereby of what is getting on a machine. Some people do not want this automatic downloading/taking over by pip of what is going onto their box. This also does not help whatsoever to understand/learn what is needed to run a particular python program. With dumping the setup.py you are driving users away. 'python3 -m pip install -U' is NOT simple at all! It breaks the common python-usage people know; it lacks and breaks the tradition; if that pip command covers/translates completely what a setup.py does (that is just writing the python files of that exact package to a given place without all the dependencies that pip drags along) than you better create a stub-file in your package that covers that command. Do not expect people to have to rewrite common scripts just to cover this change of what used to be and still is for many, common usage to install a piece of python code. HTH ROb

…

On Mon, 11 Oct 2021 02:58:02 -0700 Brian Rutledge ***@***.***> wrote: Sorry to hear that you're having trouble. `setup.py` was removed in #757 (which explains the reasoning). Are you using `python3 setup.py install` to install Twine from source? If so, the preferred approach is to use pip to install the package from the current directory: ``` python3 -m pip install -U . ``` If you run into trouble there, check your version of pip, and upgrade if necessary: ``` python3 -m pip --version python3 -m pip install -U pip ```

[brobr]

On Mon, 11 Oct 2021 04:19:55 -0700 Ian Stapleton Cordasco ***@***.***> wrote: Other linux distributions now build the wheel in order to install from a source distribution, e.g., Fedora: https://src.fedoraproject.org/rpms/python-twine/blob/51921fdf414394643792d3cf7429b02f64bdce7b/f/python-twine.spec#_65 You can use `python -m build` instead of `pyproject` as documented there

Well, 'other' does not cover 'all'. As you noticed, I am on Slackware, not on fedora. For a reason. KISS. You are ditching that principle to enforce people to do it your way. The statement: 'Now that pip supports editable installs with only setup.cfg files, and setuptools_scm recommends pyproject.toml, this seemed like a reasonable bit of housekeeping.' Hello, now I have to do something with scm, toml, cfg where my package-building scripts just could call `python setup.py install`?? Why can people not just leave the simplicity principles alone and if change needed, encapsulate these changes and translate them back to the simple interface people have grown up with!?

[sigmavirus24]

@brobr I'm a Slackware user too. Unfortunately, the rest of the world moves much faster to improve upon what exists for the benefit of all rather than cater to those who refuse to accept progress. RHEL supports far larger installation bases for far longer and manages to keep up with volunteer package managers.

Many of the tools you reference have existed for years if not over a decade. That's way more time than Slack 15 has been in development.

What may seem like well enough to you is broken for many more. I suggest that if you can't handle moving onto tooling that's been around and stable and is the best practice, then maybe use older versions. Otherwise, your hostility will not be tolerated