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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

>
> 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.

> > 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. :)

Bart

> >
> > Bart




[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux