Please allow flit to synthesize setup.py for this package

[nanonyme]

As part of bootstrapping base pep517 stack you now have distutils -> setuptools -> tomli + pep517 + build. Since you are apparently creating tarballs with --no-setup-py, this bootstrap chain is now impossible which makes pep517 a misery for distros (see pypa/pyproject-hooks#125). Can you please consider not using this switch?

[nanonyme]

Looks like "regression" (it's regression in Python ecosystem-wide bootstrappability, not in this package per se) is caused through #115

[layday]

You could theoretically rebuild tomli from the sdist using flit to generate a setup.py but that would mean adding flit somewhere in the dependency chain. Not impossible, but impracticable, for as long as bootstrapping is dependent on distutils/setuptools.

[hukkin]

Hey, thanks for the issue!

I'm a bit reluctant to add the setup.py as

• it really is there in flit only as an install-time legacy compatibility layer for old pip versions that dont support PEP517. It's not meant for building.
• The generated file uses deprecated (soon to be removed) distutils, not setuptools (3.3.0: issue with generated setup.py in entrypoints module pypa/flit#437)
• Flit will soon not be able to generate the setup.py at all so it'd be my personal burden as maintainer to create and update it after that
• The whole python setup.py <cmd> way of building, testing, or doing anything really, is deprecated.
• Most distros seem to use GitHub archives instead of PyPI sdist anyways, so they don't have access to this file but seem to be managing fine even when not using PEP517 builds

#114 has a lot of information regarding repackaging that may help you. You should be able to either

• Use PEP517 builds: Set up a process where Tomli source copy is used to build (explained e.g. here https://github.com/takluyver/flit/pull/441/files)
• Keep using legacy builds: Add a two-liner setup.py yourself. Here's what gentoo uses:

  from setuptools import setup
  setup(name="tomli", version="${PV}", packages=["tomli"], package_data={"": ["*"]})
  

Would this work for your use case?

[hukkin]

Oh and a third option that is starting to seem increasingly better IMO: persuade the right people to add a TOML parser to Python standard library 😄 Would make builds infinitely easier.

[nanonyme]

@layday you cannot use flit without first building tomli without PEP517 because pep517 (the project) depends on tomli. They're now changing the entire project to support fallbacking to toml, I would imagine in large part because toml does have setup.py.

[nanonyme]

@hukkin I don't imagine no one in their right mind would want to have their project in standard library. It essentially means infinite backwards and forwards compatibility unless you're Guido and manage to land a provisional API into standard library.

[nanonyme]

@hukkin But okay, your reasoning seems sensible, that linkage was fairly comprehensive. I have no idea how Python packaging ecosystem can possibly survive if standard library can no longer be used for bootstrapping pip and setuptools that can be used to install further things. But you're right, it's beyond of the scope of this project to worry about. That essentially means distros will be left off with hacks like get-pip.py while trying to build a pep517 build system.

[layday]

See pypa/flit#441 for recommendation on how to bootstrap flit and tomli.

[ok-dok]

so, how can I use tomli without pip in an offline environment ? I try to get a readme about building tomlib from source code, but didn‘t find it. Is there anybody can give some advices or guides?

[hukkin]

If you want to keep using legacy setup.py invocations you can do it with something like

python3 -c 'from setuptools import setup; setup(name="tomli", packages=["tomli"], package_data={"": ["*"]}, version="2.0.1")' sdist bdist_wheel

This will create a source distribution and a wheel.

If you want modern pyproject.toml based builds you should look into

• https://github.com/pypa/build to build
• https://github.com/pypa/installer to install