[mixmastamyk]

Keep it simple and fashion-proof. Been using setup.py for a one-script package for one or two? decades:

    from setuptools import setup

    setup(
        name          = 'foobar',
        scripts       = ['foo'],  # install a script from current fldr
        # ...
    )

A few years ago I had to start using twine to register and upload it to pypi.

[talideon]

I wouldn't recommend that at all these days. setup.py definitely is not future-proof: it's undergoing deprecation.

Better would be a basic pyproject.toml file along the lines of the following:

    [build-system]
    requires = ["setuptools"]
    build-backend = "setuptools.build_meta"

    [project]
    name = "foobar"
    version = "0.0.1"
    dependencies = [
        "...",
    ]

    [project.scripts]
    foo = "foobar:main"

See: https://setuptools.pypa.io/en/latest/userguide/quickstart.ht...

[eesmith]

> it's undergoing deprecation

In the "we would rather people not use this but it's going to stay around for a long time" sense. I strongly doubt it will disappear within the next decade or two. There's a long tail of setup.py-based tools.

Last I checked pyproject.toml only supports the simplest of Python/C extensions. Anything fancy, like --with/--without compilation flags to enable/disable optional support, compiler-specific flags (in my case, to add OpenMP), compile-time code generation (like using yacc/lex), etc. requires a setup.py and a bunch of hacking.

[akx]

The new style to do that is a PEP 517 build backend.

[eesmith]

Yes. That PEP comments:

> The difficulty of interfacing with distutils means that there aren’t many such systems right now, but to give a sense of what we’re thinking about see flit or bento.

Bento is dead. Flit doesn't handle extensions, and points instead to Enscons, which in turn depends on SCons - a build system I have no experience with.

Plus, I sell a source code license. My customers make wheels for their internal PyPI mirrors. I would need to consider how any change might affect them, without the experience to make that judgement.

It seems far easier for me to stay with setup.py than explore a PEP 517 alternative.

So far what I've seen is either people using something like Enscons, or a very complex build system like SciPy's where setuptools just doesn't work. I haven't seen much migration for smaller setup.py systems like mine .. but I also haven't been tracking that well enough.

Any pointers for how that would work?

[jborean93]

You should continue to use the setup.py to define the extensions but put all the remaining metadata in the pyproject.toml. The pyproject.toml will reference setuptools as your build backend like https://github.com/jborean93/pyspnego/blob/main/pyproject.to... and the setup.py will reference anything that cannot be expressed in the pyproject.toml like C extensions https://github.com/jborean93/pyspnego/blob/main/setup.py.

The benefits of this is now your project has metadata that tools like pip/poetry/etc can use to figure out what is required (Python project wise) to build your project. For example pip will create an isolated venv with setuptools and Cython for the project I listed when installing from the sdist. You can now also take advantage of `python -m build` to build this project rather than a setuptools specific incantation. This is universal across all build providers so if you want to change to poetry in the future you can will hopefully no build script changes.

[eesmith]

I know my project is an oddball. So far I have no required external dependencies, and my optional dependencies are for what the linked-to pages refer to as "native dependencies", which can't be specified by pyproject.toml.

My "setuptools specific incantation" is "pip install" or "pip install -e". I do have a setup.cfg.

The recommendation last year was "If you're building an application, use Poetry. If you're building a library, use Flit", and since my package is a library, I've never really considered poetry.

But! I'm switching from argparse to click - my first required dependency! - so within a month or so I'll be putting my toes into the pyproject.toml waters.

Thank you for your pointers. Isn't there also a way to specify the requirements for building the documentation? I didn't see it in your example.

[mixmastamyk]

“Undergoing deprecation” as in not deprecated yet. Great majority of pkgs using it, and Python takes a decade+ to deprecate things.

Also this is a few lines of well understood Python, not exactly a huge investment, right? Does several lines even need to be future proof?

My bet is you’ll need to modify the toml solution more often than the setup.py in the next decade.

[tomrod]

Is there a place you recommend where I can learn more about this?

[mixmastamyk]

It’s documented, try google, stackoverflow, and reading other packages’ setup.py for tricks.

However the scripts=[], keyword is the key to the case above.