Support projects that don't have a pyproject.toml

[AstraLuma]

For legacy projects, there's a pep517-compatible interface in setuptools to use.

bork should use mock pyproject data based on this if no pyproject.toml file is present.

[AstraLuma]

(I have a copy in gobuild.it, i just need to dig it out later.)

[AstraLuma]

{
    'build-system': {
        'build-backend': 'setuptools.build_meta:__legacy__',
        'requires': ['setuptools>=42'],
    },
}

[duckinator]

I'm unsure whether I want to have Bork automagically try this if pyproject.toml doesn't exist, but not opposed to it.

But, regardless of whether it's automatic or behind a flag (e.g. --legacy), I'm 100% in favor of this being added.

[AstraLuma]

I say that if pyproject.toml doesn't exist but setup.cfg/setup.py does exist, that's a pretty strong indication you should do that.

[duckinator]

That's fair.

[nbraud]

If we automagically inject defaults, we should at least display warnings, to push users to comply with PEP517.

I guess you are trying to use Bork as a library to build third-party projects, some of which don't have a sensible pyproject.toml, and submitting PRs everywhere would be a lot of work? (I guess scripting it might be the least-annoying)

[AstraLuma]

Possibly? But it is a valid python project that will likely be supported by the broader ecosystem for a long, long time.

[duckinator]

I'm okay with showing a warning.

I did realize, however, that I don't think setup.py is exclusively used by setuptools (iirc, at least distutils also uses it). So I'm not sure how we'd reliably auto-detect it.

[duckinator]

If we can't find a way to auto-detect it, I'm still okay with adding a flag to use the legacy backend.

[AstraLuma]

Distutils is a the older standard library core of setuptools.

Their relationship is complicated.

[AstraLuma]

I think using setuptools for projects that are technically distutils is fine.

[nbraud]

Possibly? But it is a valid python project that will likely be supported by the broader ecosystem for a long, long time.

Assuming “it” refers to setuptools, I'm not sure I see why “being supported by the broader ecosystem” means its users get not to do the right thing and comply with PEP517 (especially when doing so is trivial).

Odd 4am thought: would it make sense to refuse handing a project without a pyproject.toml and instead suggest (based on the presence of setup.{cfg, py}) the right contents for it?

[duckinator]

Honestly, I'm still having trouble coming to a useful conclusion on this. The ability to migrate existing projects is important, but the main usecase is for projects already using PEP 517. And it feels like these aren't at odds, but also aren't exactly aligned.

Would it make sense to have a second frontend that either uses the normal Bork entrypoint for PEP517 projects, or injects the appropriate pyproject.toml for non-PEP517 projects?

(Like "autobork", or maybe something less ridiculous sounding than that. Or maybe not, since "bork" itself is pretty silly.)

[duckinator]

I'm not sure I see why “being supported by the broader ecosystem” means its users get not to do the right thing and comply with PEP517 (especially when doing so is trivial).

I think there's two different usecases here: Using Bork as the primary project management utility, and to build projects you don't have direct control over.

[nbraud]

Amusingly, it looks like things happen to work with an empty pyproject.toml.

I don't know whether it's something that build guarantees, but I don't think we want to encourage that, as it's a clear violation of PEP 517 and 518 ; might be worth looking into it and possibly filing a bug, but I don't particularly want to engage that much with PyPA.

[nbraud]

I'm not sure I see why “being supported by the broader ecosystem” means its users get not to do the right thing and comply with PEP517 (especially when doing so is trivial).

I think there's two different usecases here: Using Bork as the primary project management utility, and to build projects you don't have direct control over.

Agreed. @AstraLuma, it would be helpful if you clarified what's your usecase.

[AstraLuma]

It's the build case: building projects I don't have direct control over, or where changes are expensive.

[nbraud]

It's the build case: building projects I don't have direct control over, or where changes are expensive.

Sure, but why are you doing it, and why are you doing it with bork?

(Edit: to be clear, I'm not trying to be difficult, I'm just trying to understand what's your usecase)

[AstraLuma]

because bork is an easy "just build it" tool