Remove Python version floor

[ucodery]

Fixes #62

[willingc]

Seems reasonable with some comments.

[willingc]

I think this is ok to remove.

[sneakers-the-rat]

Idk how hatch handles it, but if I remove version floors in pdm then it goes hogwild trying to find versions that also dont have version floors when resolving the environment. I see we have encountered that with myst already.

I think it relates to conversations in other issues - is this supposed to be "best practices python template" or "arbitrary flexible python template?" I think usually best practices would say that you dont want to allow for a version that you dont test for/arent sure if it works. Bc you're right, we don't know the resulting package will be 3.10 and up.

Dep resolution is my only concern, but if hatch is fine with it then I am too. Like what happens when we try to add scipy or something to the deps, does it get resolved as some super ancient version?

Edit: I guess secondary concern is if this gets new programmers that are using this in a difficult spot thats hard to understand. I'll give it a whirl and see what it does when I start adding deps

[ucodery]

@sneakers-the-rat I haven't used PDM, but I'm a bit surprised if having no requires-python makes it go wild. There has to be more packages out there without one than with. I do know that Poetry goes wild when you try to add a ceiling to requires-python because it wants your version range to be a strict sub-set of your dependencies' and that's harder with two bounds.

[ucodery]

This can also be a list, e.g. ["3.10", "3.11", "3.12"], but I don't think we want to matrix docs builds. And hatch doesn't seem to support open ended version ranges ">=3.10" :(

[sneakers-the-rat]

I think eventually we'll want to start taking all these consts out of the templates themselves and into .yaml files that we load into the template contexts, so this is totally fine to me and in the future we can give ourselves a handle if we want to have better control over the python version in the generated project.

[sneakers-the-rat]

tested this out, no problem, hatch doesn't resolve a dep graph so requires-python looks like it has no effect except on downstream packages

[Midnighter]

I get that there is no need for being restrictive on the lower version, however, I would generally like to encourage new projects to start with a relatively new version. No need to start with old syntax if there is no good reason for it.

[ucodery]

It's not always about not using old (deprecated) syntax, it's about not using new syntax. The whole Fall Festival the only syntax used was def, if, else, try, except, import. I am for encouraging newer interpreters, but setting this floor makes it harder to use without also teaching an interpreter upgrade story.

[sneakers-the-rat]

If you're not generating lockfiles, I think that the floor is only necessary when you want to signal that a version is known to be incompatible with a python version so when it is installed pip or other installers will iterate through prior versions until it finds one with a requires-python that includes the currently running python version.

the only time that would cause a problem is if the package used language features unsupported by the installing version, or packages that have no version that's compatible with the installing version. it seems like having a floor and not having a floor both have potential gotchas for new programmers: with the floor they might run into a problem where pip is telling them they can't install the package, and without the floor they might run into a problem eventually where someone tries to use their package with an old python and they, eg. have used the | syntax or some other feature not available in that version.

Having the floor would cause the problem sooner, and not having it would cause it later in a way that might cause some harder-to-handle but less likely problems like having to issue postrelease patches for all the versions that didn't have a floor until the last version that was compatible with the old python. To me it's a wash which is preferable from a principle of least surprise POV, though I see where @ucodery is coming from w/ not adding a constraint until it's known to be needed.

edit: fwiw, the oldest python version hatch is able to use seems to be 3.7, and the base "import the package" test seems to work in 3.7, though that's not really saying much :)

edit2: actually now that i'm thinking of this, the ruff rule being ALL would include pyupgrade would probably force someone to use some newer language features sooner or later. but i remain neutral-positive about this change

[Midnighter]

There are good arguments for removing the lower bound.

[ucodery]

Thanks all. @lwasser I don't think I have merge permissions here, so I will leave it for whomever does.

[sneakers-the-rat]

i click da boton