Re: [libgpiod][PATCH v4 1/1] bindings: python: optionally include module in sdist

[Phil Howard <phil@xxxxxxxxxxxxx>]

On Tue, 17 Oct 2023 at 12:29, Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
>
> On Tue, Oct 17, 2023 at 1:15 PM Phil Howard <phil@xxxxxxxxxxxxx> wrote:
> >
> > On Tue, 17 Oct 2023 at 11:09, Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
> > >
> > > On Mon, Oct 16, 2023 at 5:18 PM Phil Howard <phil@xxxxxxxxxxxxx> wrote:
> > > >
> > > > Optionally vendor libgpiod source into sdist so that the
> > > > Python module can be built from source, even with a missing
> > > > or mismatched system libgpiod.
> > > >
> > > > Add optional environment variable "LINK_SYSTEM_LIBGPIOD=1"
> > > > so that the sdist package can optionally be built and
> > > > linked against a compatible system libgpiod.
> > > >
> > > > eg: LINK_SYSTEM_LIBGPIOD=1 pip install libgpiod
> > > >
> > > > Update build to add an additional sdist target for upload
> > > > to pypi. Call setup.py with "GPIOD_VERSION_STR" set, which
> > > > triggers a vendored package build. "GPIOD_VERSION_STR" is
> > > > saved to "gpiod-version-str.txt" and included in the sdist
> > > > for standalone builds.
> > > >
> > > > "GPIOD_VERSION_STR" must be specified in order to produce
> > > > a standalone buildable sdist package, this requirement
> > > > implicitly preserves the old build behaviour.
> > > >
> > > > Signed-off-by: Phil Howard <phil@xxxxxxxxxxxxx>
> > > > ---
> > >
> > > Alright, this looks and works well. Before I merge it: the package
> > > still shows up in 'pip freeze' as libgpiod. Now that we control the
> > > name 'gpiod' on pypi, should we change it to 'gpiod' instead?
> >
> > Yes, it's conventional to have the module and package name match
> > for single module packages.
> >
> > > Once I apply the patch - how would we go about making a new proper
> > > release?
> >
> > The "libgpiod-2.0.1.tar.gz" (or "gpiod-2.0.1.tar.gz" if we change it) should
> > be uploaded to pypi via the utility "twine" (pip install twine). You can upload
> > versions to testpypi by specifying "--repository testpypi" which, combined
> > with a "-postN" version suffix, can help work through bugs in packaging or
> > README formatting.
> >
> > You can also run "twine check dist/*" to precheck for packaging issues.
>
> Sure, this is how I uploaded the existing releases. I was thinking
> more about versioning. We haven't added new interfaces to the code so
> I think the version should be set to v2.0.2 as technically this is a
> bug-fix release + build improvements.

Agreed.

> >
> > I'm not sure if we should yank prior releases of the Python gpiod but
> > some note in the README paying lip service to the change from unofficial
> > Python to official C-bindings would be wise.
> >
>
> You mean out of the "gpiod" repo, not "libgpiod"? Because I assume
> this is where we'll upload the new release.

Yes since new packages will be uploaded to the "gpiod" pypi repo they
are going to be seen as an "update" to the old "gpiod".

Something like "For the old unofficial Python gpiod install with:
pip install gpiod==1.5.4" should suffice.

There's good evidence [1] that gpiod is at least moderately popular so we
should expect some minor fallout from people who refuse to pin their deps.

[1] - https://pypistats.org/packages/gpiod

>
> > > Do you also want to add a better homepage to setup.py so that
> > > users of pypi don't bounce off the nonexistent documentation?
> >
> > Yes, we need a basic introduction and a couple of succinct examples.
> >
> > I have some half done edits to the README somewhere locally which I
> > was holding back until after we got the packaging working and until I
> > could ask: What format would you prefer for the README?
> >
>
> Whatever works best or is the standard for pypi. You are the expert. :)

I prefer Markdown because it's what I know and use. I don't believe
any specific format is preferred these days- though the fallback default is
'text/x-rst'

>
> Bart
>
> > >
> > > Bart