hatch?

[Schamschula]

For a downstream port maintainer, in my case for MacPorts, this means adding another build system, incompatible with all the others currently in use.

[facelessuser]

Yes?

[facelessuser]

Let me mention, that it is becoming discouraged to use setup.py. I do some dynamic things in my setup, so I opted to use a build system that I find flexible. It is compatible with the recent related PEPs.

[Schamschula]

That is well known. However, if you look at the MacPorts python build system (PortGroup) you'll see why I don't want to hack in another backend.

See: https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/python-1.0.tcl

[facelessuser]

I understand, with that said, people are naturally going to gravitate toward a system that works well for their project. If it isn't SoupSieve now, it will be some other project in the future. Is the plan to campaign against a new useful build backend? I don't think that serves anyone but macports.

[facelessuser]

Just to clarify, the new tox rewrite looks to be using Hatch as well: https://github.com/tox-dev/tox/blob/rewrite/pyproject.toml#L2.

[Schamschula]

It's your choice. We'll see how fast other ports systems update to 2.3.2.

However, what it means is that I'm likely to drop maintainership of py-soupsieve. I only maintain it as it is a dependency of other projects I maintain and/or use.

[facelessuser]

I'm not against other forms of distribution of this project or any of my projects, but I primarily target pip. I'm also not inflexible, but this hasn't really been a conversation as much as an ultimatum to change to what macports supports or be dropped.

If people desire to use SoupSieve, they'll go where they can get it. If macports wants to be that place, they'll also support it, and if they don't, then I guess they won't.

Regardless of whether py-soupsieve is on macports, there will be more projects coming that support Hatch.pipx is already on macports and is also switching to Hatch as well: https://github.com/pypa/pipx/blob/main/pyproject.toml#L2. If port systems want to maintain support for existing Python libraries, supporting Hatch is something that will need to be considered.

[Schamschula]

It certainly was not meant to be an ultimatum, just a expression of frustration.

However, as someone maintaining numerous ports, adding at least three new ports and adding a new build system to support a point release update causes quite a bit of work.

Particularly, changing the build system requires a PR to be approved by the maintainers of the port group, which will take some time.

I can understand the pip approach. But for most other build/ports systems it is a blocker of a problem, as we have multiple entities maintaining and updating python packages. This leads to broken and/or missing dependencies.

As far as pipx switching to hatch it won't happen without the same changes. It is currently up to date, so py-soupeseive is the first package to require this modification.

[facelessuser]

It certainly was not meant to be an ultimatum, just a expression of frustration.

That makes sense, and I do understand that. My intention was not to cause a headache in distribution chains, but was to bring the build process in compliance with future requirements in a way I felt was the most reasonable, and easy for me to maintain.

The direction that Python is moving is unfortunately the cause of this, and while the situation is not ideal, it is sadly the logical outcome. Hopefully, this direction that Python is moving in will not spawn numerous more build backends, but as people are forced to move from the tried and true methods, and evaluate the options, it isn't surprising that at least one new option popped up to address what was viewed as limitations of the current competing backends.

The good news is that hatch does conform to pep517, and hatchling can be used as a backend in the python port group.

This was one of the reasons I switched to it.

I was hesitant myself to switch to Hatch when it was first proposed in another one of my projects. Seeing that it was relatively easy to convert over to and could handle the needs of all my projects, that it was compliant with the related PEPs, and seeing some bigger projects also starting to move eased my mind about it.

As far as pipx switching to hatch it won't happen without the same changes. It is currently up to date, so py-soupeseive is the first package to require this modification.

Yeah, this may be one of the earlier ones to actually release the change.

[Schamschula]

The good news is that hatch does conform to pep517, and hatchling can be used as a backend in the python port group.

I'll be pushing the new ports and a PR for the python port group.

[Schamschula]

Unfortunately, I have to keep the old build for version 2.3.1 to support the python 3.6 dependencies. There are still 9 packages left.

[facelessuser]

There shouldn't be anything that prevents installation on 3.6. I don't advertise that we still support 3.6, but I did not require 3.7+, it is still allowing 3.6+.

[facelessuser]

I do plan on the next major release to cut off 3.6, but I did not want to require such a change in a bugfix release. I've successfully installed it via 3.6 on my work machine. As my company still uses 3.6, I haven't been forbidding 3.6...yet.

[Schamschula]

It's the hatch/hatchling ports that don't support 3.6, not py-soupsieve itself.

[facelessuser]

That's odd, because I installed the latest via pip on Python 3.6.:

Python 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 24 2018, 00:16:47) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import soupsieve
>>> soupsieve.__version__
'2.3.2'

[facelessuser]

If that is truly the case, it is possible I could roll another bugfix cherry-picking the latest fixes on top of 2.3.1. The intention was not to lockout a Python version on a bugfix release.

[Schamschula]

In hatch itself https://github.com/ofek/hatch/blob/master/pyproject.toml

has

requires-python = ">=3.7"

[facelessuser]

That's weird that pip allowed me to use it on 3.6 then 😕.

I'll create a bugfix that resolves this. The next major release though will definitely drop Py3.6 then. That might be a while though as things are pretty stable and there are no new CSS selectors we are planning on picking up until they mature in the CSS spec.

[Schamschula]

However, technically I am only using the hatchling backend. I don't see any additional requirements for hatchling.

[facelessuser]

🤷🏻 I don't know, I'm more than happy to release another bugfix if necessary. But if you don't need me to, I won't bother.

[Schamschula]

Unless there is a critical issue, I'd just leave 3.6 @ soupsieve 2.3.1.

I hope that the remaining 9 dependent ports drop 3.6 support in the near future.

[ofek]

Small update: Hatch will be adopted by PyPA soon

• https://mail.python.org/archives/list/[email protected]/thread/J2BL5XTTOCXUCELUE7L5P5HHJ7NXZGZ5/
• https://mail.python.org/archives/list/[email protected]/thread/ZWSSNKQJ3GRIAK73FJS6KHOJNUJZYOVX/

Nothing major will change, just the repo location

[facelessuser]

Happy to see it get adopted by PyPA.