Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #14136 > unrolled thread

Re: a review of your bumblebee-status package

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: a review of your bumblebee-status package Ben Westover <kwestover.kw@gmail.com> - 2022-06-07 02:10 +0200
    Re: a review of your bumblebee-status package Ben Westover <kwestover.kw@gmail.com> - 2022-06-07 03:20 +0200
      Re: a review of your bumblebee-status package Antoine Beaupré <anarcat@debian.org> - 2022-06-07 04:30 +0200
        Re: a review of your bumblebee-status package Ben Westover <kwestover.kw@gmail.com> - 2022-06-07 04:50 +0200
          Re: a review of your bumblebee-status package Andrey Rahmatullin <wrar@debian.org> - 2022-06-07 08:20 +0200
          Re: a review of your bumblebee-status package Julian Gilbey <julian@d-and-j.net> - 2022-06-07 08:20 +0200
            Re: a review of your bumblebee-status package Antoine Beaupré <anarcat@debian.org> - 2022-06-07 15:50 +0200
              Re: a review of your bumblebee-status package Julian Gilbey <julian@d-and-j.net> - 2022-06-07 16:50 +0200
                Re: a review of your bumblebee-status package Julian Gilbey <julian@d-and-j.net> - 2022-06-07 17:00 +0200
                  Re: a review of your bumblebee-status package Ben Westover <kwestover.kw@gmail.com> - 2022-06-08 00:50 +0200
                    Re: a review of your bumblebee-status package Antoine Beaupré <anarcat@debian.org> - 2022-06-08 15:30 +0200
                Re: a review of your bumblebee-status package Antoine Beaupré <anarcat@debian.org> - 2022-06-07 17:00 +0200
          Re: a review of your bumblebee-status package Antoine Beaupré <anarcat@debian.org> - 2022-06-07 15:50 +0200
            Re: a review of your bumblebee-status package Julian Gilbey <julian@d-and-j.net> - 2022-06-07 17:00 +0200
              Re: a review of your bumblebee-status package Julian Gilbey <julian@d-and-j.net> - 2022-06-07 17:10 +0200
          Versioneer [was Re: a review of your bumblebee-status package] Timo Röhling <roehling@debian.org> - 2022-06-07 16:30 +0200
            Re: Versioneer [was Re: a review of your bumblebee-status package] Paul Wise <pabs@debian.org> - 2022-06-08 03:30 +0200

#14136 — Re: a review of your bumblebee-status package

[Multipart message — attachments visible in raw view] — view raw

Bonjour Antoine,

I already discussed this topic with you in IRC, but I'm documenting the 
details here for the sake of the mailing list.

>   * i wonder if bumblebee-status/_version.py belongs there. it's a copy
>     of the python3-versioneer package that's already in the
>     archive... could you remove it from the source and make sure we use
>     the Debian copy instead? at the very least the debian/copyright file
>     should refer to it...

_version.py is not a copy of versioneer, it's *generated* by versioneer. 
However, there is versioneer.py in the root directory, which is. I'll 
exclude that from the source and repack.

>   * i also attach the output of `decopy` which finds a few more things
>     than you in debian/copyright
> 
>   * i'm really not sure I like that C binary to fetch the keyboard
>     layout... surely there must be a more pythonic way of doing this? i
>     guess there's another layout-xkb module that does the right thing,
>     but it seems odd to have both there.. you also seem to rebuild it in
>     debian/rules, but i don't see where it gets installed

I'm just following what was done upstream (except removing a prebuilt 
binary in the source that I then rebuild).

As for how it's installed, I believe that's handled by the upstream 
setup.py:
     data_files=[
         ("share/bumblebee-status/themes", glob.glob("themes/*.json")),
         ("share/bumblebee-status/themes/icons", 
glob.glob("themes/icons/*.json")),
         ("share/bumblebee-status/utility", glob.glob("bin/*")),
     ]
Looks like it's put into /something/share/bumblebee-status/utility.

One flaw I did find is that my package is marked for architecture all, 
while in reality it should be marked as any because of this C binary.

>   * i did a quick read of most of the code in commit
>     30853fd19110c6e53be35c4bb846ab3a133b51ac and it seems sane. i haven't
>     reviewed the contrib modules
> 
>   * the build fails here, in a fresh Debian unstable qemu image, with:
> 
>         ERROR tests/core/test_output.py - RuntimeError: unable to find theme default

I am aware of this failure and have reported it upstream. For now, I'll 
disable the offending test.

> 
> I attach a full build log.
> 
> Thanks for working on this package!
> 
> a.
> 
> 
> 
> anarcat@curie:bumblebee-status$ decopy
> Building tree: 56dir [00:00, 2629.63dir/s]
> Queueing: 739file [00:00, 1586.90file/s]
> Processing: 100%|██████████████████████████████| 683/683 [00:10<00:00, 63.52file/s]
> Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> Upstream-Name: bumblebee-status
> Upstream-Contact: tobi-wan-kenobi
> Source: https://github.com/tobi-wan-kenobi/bumblebee-status
> Files-Excluded: bin/get-kbd-layout
> Comment: Removed x86_64 Linux binary with source available in the same repo
> 
> Files: *
> Copyright: 2015, Marc Herndon and GPL2
>             2017, Oscar Svensson
>             2017, Oscar Svensson (wogscpar) under MIT licence from upower-python
>             Public Domain
> License: Expat or MIT
> 
> Files: LICENSE
> Copyright: 2016, tobi-wan-kenobi
> License: Expat
> 
> Files: bumblebee_status/_version.py
> License: public-domain
> 
> Files: debian/*
> Copyright: 2022, Ben Westover <kwestover.kw@gmail.com>
> License: MIT
> 
> License: Expat
> Comment: Add the corresponding license text here
> 
> License: MIT
>   Permission is hereby granted, free of charge, to any person obtaining a copy
>   of this software and associated documentation files (the "Software"), to deal
>   in the Software without restriction, including without limitation the rights
>   to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
>   copies of the Software, and to permit persons to whom the Software is
>   furnished to do so, subject to the following conditions:
>   .
>   The above copyright notice and this permission notice shall be included in all
>   copies or substantial portions of the Software.
>   .
>   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>   IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>   FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
>   AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>   LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
>   OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
>   SOFTWARE.
> 
> License: public-domain
> Comment: Add the corresponding license text here
> 

This autogenerated copyright file has some problems. First of all, 
LICENSE shouldn't be considered separate from the rest of the source, 
since it describes the entire source. Also, as far as Debian is 
concerned, MIT and Expat are the same license (although in reality MIT 
is a term used to describe two slightly different licenses). The 
copyright holder for * is incorrect, I don't know where it got that info 
from. It did catch _version.py, which I didn't, so I'll add that.

Merci d'avoir examiné mon paquet,
--
Ben Westover

[toc] | [next] | [standalone]

#14138

[Multipart message — attachments visible in raw view] — view raw

Hello again,
Some corrections to my previous message:

> As for how it's installed, I believe that's handled by the upstream setup.py:
>      data_files=[
>          ("share/bumblebee-status/themes", glob.glob("themes/*.json")),
>          ("share/bumblebee-status/themes/icons", glob.glob("themes/icons/*.json")),
>          ("share/bumblebee-status/utility", glob.glob("bin/*")),
>      ]
> Looks like it's put into /something/share/bumblebee-status/utility.

Confirmed that it's /usr/share/bumblebee-status/utility.

>>   * the build fails here, in a fresh Debian unstable qemu image, with:
>>
>>         ERROR tests/core/test_output.py - RuntimeError: unable to find 
>> theme default
> 
> I am aware of this failure and have reported it upstream. For now, I'll 
> disable the offending test.

After doing that, I discovered that almost all of the tests are faulty 
(at least on Python 3.10), so I've disabled tests altogether for now.

> As far as Debian is concerned, MIT and Expat are the same license > (although in reality MIT is a term used to describe two slightly
> different licenses).
I was corrected by pabs on IRC; Debian does in fact prefer the use of 
the terms Expat and X11 to be separate and not to use the term MIT.
I was used to the way the Rust team does things, which uses MIT.

--
Ben Westover

[toc] | [prev] | [next] | [standalone]

#14139

On 2022-06-06 21:10:31, Ben Westover wrote:
> Hello again,
> Some corrections to my previous message:
>
>> As for how it's installed, I believe that's handled by the upstream setup.py:
>>      data_files=[
>>          ("share/bumblebee-status/themes", glob.glob("themes/*.json")),
>>          ("share/bumblebee-status/themes/icons", glob.glob("themes/icons/*.json")),
>>          ("share/bumblebee-status/utility", glob.glob("bin/*")),
>>      ]
>> Looks like it's put into /something/share/bumblebee-status/utility.
>
> Confirmed that it's /usr/share/bumblebee-status/utility.
>
>>>   * the build fails here, in a fresh Debian unstable qemu image, with:
>>>
>>>         ERROR tests/core/test_output.py - RuntimeError: unable to find 
>>> theme default
>> 
>> I am aware of this failure and have reported it upstream. For now, I'll 
>> disable the offending test.
>
> After doing that, I discovered that almost all of the tests are faulty 
> (at least on Python 3.10), so I've disabled tests altogether for now.

Does the package *work* at all in 3.10? We might not want to silence
real errors here...

> _version.py is not a copy of versioneer, it's *generated* by versioneer. 
> However, there is versioneer.py in the root directory, which is. I'll 
> exclude that from the source and repack.

hmm... how about that generated file though? shouldn't it be ... well,
generated at build time instead? :)

let me know when / if you need me to look at it again, and thanks again!

a.
-- 
Every time I see an adult on a bicycle I no longer despair for the
future of the human race.
                         - H. G. Wells

[toc] | [prev] | [next] | [standalone]

#14140

[Multipart message — attachments visible in raw view] — view raw

Hello Antoine,

>>> I am aware of this failure and have reported it upstream. For now, I'll
>>> disable the offending test.
>>
>> After doing that, I discovered that almost all of the tests are faulty
>> (at least on Python 3.10), so I've disabled tests altogether for now.
> 
> Does the package *work* at all in 3.10? We might not want to silence
> real errors here...

Upstream says 3.4-3.9 is supported, but I don't know if that's because 
3.10 doesn't work or because they haven't bothered to add it. Searching 
their bug tracker, I wasn't able to find any 3.10-related issues yet.
I also haven't tried to use the program with Python 3.10, because I 
don't use it myself at all (packaging this for a friend).

>> _version.py is not a copy of versioneer, it's *generated* by versioneer.
>> However, there is versioneer.py in the root directory, which is. I'll
>> exclude that from the source and repack.
> 
> hmm... how about that generated file though? shouldn't it be ... well,
> generated at build time instead? :)

As far as I understand it, this file is used by the author of the 
program, not end users. I don't understand it well, though, because I 
haven't put much time into researching what versioneer even does.
If my hunch is correct, I may be able to just remove the file from the 
source altogether, but I haven't tried that yet.

> let me know when / if you need me to look at it again, and thanks again!

It should be ready for review now, as long as I haven't messed anything 
up majorly in my attempts to fix the issues you brought to my attention.

Thanks again,
--
Ben Westover

[toc] | [prev] | [next] | [standalone]

#14142

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jun 06, 2022 at 10:42:53PM -0400, Ben Westover wrote:
> > Does the package *work* at all in 3.10? We might not want to silence
> > real errors here...
> 
> Upstream says 3.4-3.9 is supported, but I don't know if that's because 3.10
> doesn't work or because they haven't bothered to add it. Searching their bug
> tracker, I wasn't able to find any 3.10-related issues yet.
> I also haven't tried to use the program with Python 3.10, because I don't
> use it myself at all (packaging this for a friend).
This is a really bad idea IMO.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#14143

Hi Ben,

On Mon, Jun 06, 2022 at 10:42:53PM -0400, Ben Westover wrote:
> > > _version.py is not a copy of versioneer, it's *generated* by versioneer.
> > > However, there is versioneer.py in the root directory, which is. I'll
> > > exclude that from the source and repack.
> > 
> > hmm... how about that generated file though? shouldn't it be ... well,
> > generated at build time instead? :)
> 
> As far as I understand it, this file is used by the author of the program,
> not end users. I don't understand it well, though, because I haven't put
> much time into researching what versioneer even does.
> If my hunch is correct, I may be able to just remove the file from the
> source altogether, but I haven't tried that yet.

As far as I understand, versioneer (or the _version.py generated by
it) uses a whole bunch of heuristics to determine the version number
of the package, for example by looking at git tags and so on.  Several
times, I have found that _version.py in the PyPI release of a package
is a very small file (just a few lines long) stating the version
number of the package, while the _version.py in GitHub is huge and
doesn't work on a standalone packaged version.  If I recall correctly,
In more than one package I (co-)maintain, I've gone for the PyPI
version of this file.

Hope this helps!

   Julian

[toc] | [prev] | [next] | [standalone]

#14148

On 2022-06-07 07:11:15, Julian Gilbey wrote:
> Hi Ben,
>
> On Mon, Jun 06, 2022 at 10:42:53PM -0400, Ben Westover wrote:
>> > > _version.py is not a copy of versioneer, it's *generated* by versioneer.
>> > > However, there is versioneer.py in the root directory, which is. I'll
>> > > exclude that from the source and repack.
>> > 
>> > hmm... how about that generated file though? shouldn't it be ... well,
>> > generated at build time instead? :)
>> 
>> As far as I understand it, this file is used by the author of the program,
>> not end users. I don't understand it well, though, because I haven't put
>> much time into researching what versioneer even does.
>> If my hunch is correct, I may be able to just remove the file from the
>> source altogether, but I haven't tried that yet.
>
> As far as I understand, versioneer (or the _version.py generated by
> it) uses a whole bunch of heuristics to determine the version number
> of the package, for example by looking at git tags and so on.  Several
> times, I have found that _version.py in the PyPI release of a package
> is a very small file (just a few lines long) stating the version
> number of the package, while the _version.py in GitHub is huge and
> doesn't work on a standalone packaged version.  If I recall correctly,
> In more than one package I (co-)maintain, I've gone for the PyPI
> version of this file.

Uh! So you just keep the file around altogether? That seems like a break
of policy...

-- 
On reconnait la grandeur et la valeur d'une nation à la façon dont
celle-ci traite ses animaux.
                        - Mahatma Gandhi

[toc] | [prev] | [next] | [standalone]

#14152

On Tue, Jun 07, 2022 at 09:47:33AM -0400, Antoine Beaupré wrote:
> On 2022-06-07 07:11:15, Julian Gilbey wrote:
> > [...]
> > As far as I understand, versioneer (or the _version.py generated by
> > it) uses a whole bunch of heuristics to determine the version number
> > of the package, for example by looking at git tags and so on.  Several
> > times, I have found that _version.py in the PyPI release of a package
> > is a very small file (just a few lines long) stating the version
> > number of the package, while the _version.py in GitHub is huge and
> > doesn't work on a standalone packaged version.  If I recall correctly,
> > In more than one package I (co-)maintain, I've gone for the PyPI
> > version of this file.
> 
> Uh! So you just keep the file around altogether? That seems like a break
> of policy...

Maybe I wasn't clear: we pack the GitHub as the .orig.tar.gz and then
apply a patch (in debian/patches) to replace _version.py with the
version found in the PyPI package.  (There are often good reasons to
prefer the GitHub version over the PyPI version.)  I just looked
through my local packages and the only examples I could find were the
now-removed python-language-server and python-jsonrpc-server.

I'm not sure how this would break policy.

Best wishes,

   Julian

[toc] | [prev] | [next] | [standalone]

#14153

On Tue, Jun 07, 2022 at 10:51:08AM -0400, Antoine Beaupré wrote:
> It seems to me that generated files shouldn't be shipped as part of the
> source we distributed to users. Those files should be (re)generated at
> build time.

Ah, I understand you better now.  Debian is full of generated files
distributed in source packages.  Most of them could be regenerated at
build time, but it's often not done.  (If they cannot be regenerated
from source, then there's a DFSG issue.)  A search of the mailing list
archives would probably find many discussions about this; I'm not sure
what the current consensus is.

Best wishes,

   Julian

[toc] | [prev] | [next] | [standalone]

#14159

[Multipart message — attachments visible in raw view] — view raw

Hello,

I've read more into versioneer, and it turns out with the way it works 
you can't simply remove versioneer.py from the source, much less 
_version.py. Therefore, I'm excluding _version.py in d/copyright, then 
replacing it with the much smaller PyPI version in d/patches, and not 
touching versioneer.py at all, since with the way versioneer works it's 
technically not vendoring.

Thanks,
--
Ben Westover

[toc] | [prev] | [next] | [standalone]

#14166

On 2022-06-07 18:46:37, Ben Westover wrote:
> Hello,
>
> I've read more into versioneer, and it turns out with the way it works 
> you can't simply remove versioneer.py from the source, much less 
> _version.py. Therefore, I'm excluding _version.py in d/copyright, then 
> replacing it with the much smaller PyPI version in d/patches, and not 
> touching versioneer.py at all, since with the way versioneer works it's 
> technically not vendoring.

Got it, thanks for bearing with me here.
-- 
The destiny of Earthseed is to take root among the stars.
                        - Octavia Butler

[toc] | [prev] | [next] | [standalone]

#14154

On 2022-06-07 15:44:28, Julian Gilbey wrote:
> On Tue, Jun 07, 2022 at 09:47:33AM -0400, Antoine Beaupré wrote:
>> On 2022-06-07 07:11:15, Julian Gilbey wrote:
>> > [...]
>> > As far as I understand, versioneer (or the _version.py generated by
>> > it) uses a whole bunch of heuristics to determine the version number
>> > of the package, for example by looking at git tags and so on.  Several
>> > times, I have found that _version.py in the PyPI release of a package
>> > is a very small file (just a few lines long) stating the version
>> > number of the package, while the _version.py in GitHub is huge and
>> > doesn't work on a standalone packaged version.  If I recall correctly,
>> > In more than one package I (co-)maintain, I've gone for the PyPI
>> > version of this file.
>> 
>> Uh! So you just keep the file around altogether? That seems like a break
>> of policy...
>
> Maybe I wasn't clear: we pack the GitHub as the .orig.tar.gz and then
> apply a patch (in debian/patches) to replace _version.py with the
> version found in the PyPI package.  (There are often good reasons to
> prefer the GitHub version over the PyPI version.)  I just looked
> through my local packages and the only examples I could find were the
> now-removed python-language-server and python-jsonrpc-server.
>
> I'm not sure how this would break policy.

It seems to me that generated files shouldn't be shipped as part of the
source we distributed to users. Those files should be (re)generated at
build time.

a.

-- 
Be who you are and say what you feel
Because those who mind don't matter
And those who matter don't mind.
                         - Dr. Seuss

[toc] | [prev] | [next] | [standalone]

#14149

On 2022-06-06 22:42:53, Ben Westover wrote:
> Hello Antoine,
>
>>>> I am aware of this failure and have reported it upstream. For now, I'll
>>>> disable the offending test.
>>>
>>> After doing that, I discovered that almost all of the tests are faulty
>>> (at least on Python 3.10), so I've disabled tests altogether for now.
>> 
>> Does the package *work* at all in 3.10? We might not want to silence
>> real errors here...
>
> Upstream says 3.4-3.9 is supported, but I don't know if that's because 
> 3.10 doesn't work or because they haven't bothered to add it. Searching 
> their bug tracker, I wasn't able to find any 3.10-related issues yet.
> I also haven't tried to use the program with Python 3.10, because I 
> don't use it myself at all (packaging this for a friend).

I think it's worth doing a trial run in an actual unstable VM before
disabling those tests. Otherwise we're just guessing and we might put a
completely non-working package out there... That's going to help no one:
neither our users or upstream...

>>> _version.py is not a copy of versioneer, it's *generated* by versioneer.
>>> However, there is versioneer.py in the root directory, which is. I'll
>>> exclude that from the source and repack.
>> 
>> hmm... how about that generated file though? shouldn't it be ... well,
>> generated at build time instead? :)
>
> As far as I understand it, this file is used by the author of the 
> program, not end users. I don't understand it well, though, because I 
> haven't put much time into researching what versioneer even does.
> If my hunch is correct, I may be able to just remove the file from the 
> source altogether, but I haven't tried that yet.

Well, it's used by the program to show the version info, so it's
*eventually* used by users for sure.

I think just removing the file is a good first guess.

>> let me know when / if you need me to look at it again, and thanks again!
>
> It should be ready for review now, as long as I haven't messed anything 
> up majorly in my attempts to fix the issues you brought to my attention.

Did you remove the versioneer file though?

-- 
Striving for social justice is the most valuable thing to do in life
                       - Albert Einstein

[toc] | [prev] | [next] | [standalone]

#14156

On Tue, Jun 07, 2022 at 09:47:14AM -0400, Antoine Beaupré wrote:
> >>> _version.py is not a copy of versioneer, it's *generated* by versioneer.
> >>> However, there is versioneer.py in the root directory, which is. I'll
> >>> exclude that from the source and repack.
> >> 
> >> hmm... how about that generated file though? shouldn't it be ... well,
> >> generated at build time instead? :)
> >
> > As far as I understand it, this file is used by the author of the 
> > program, not end users. I don't understand it well, though, because I 
> > haven't put much time into researching what versioneer even does.
> > If my hunch is correct, I may be able to just remove the file from the 
> > source altogether, but I haven't tried that yet.
> 
> Well, it's used by the program to show the version info, so it's
> *eventually* used by users for sure.
> 
> I think just removing the file is a good first guess.

Removing the file is a bad idea!  Replacing it with the PyPI version
(through debian/patches) is a much better approach.  (And possibly
excluding the file in debian/copyright as well.)

   Julian

[toc] | [prev] | [next] | [standalone]

#14157

On Tue, Jun 07, 2022 at 03:59:22PM +0100, Julian Gilbey wrote:
> > > As far as I understand it, this file is used by the author of the 
> > > program, not end users. I don't understand it well, though, because I 
> > > haven't put much time into researching what versioneer even does.
> > > If my hunch is correct, I may be able to just remove the file from the 
> > > source altogether, but I haven't tried that yet.
> > 
> > Well, it's used by the program to show the version info, so it's
> > *eventually* used by users for sure.
> > 
> > I think just removing the file is a good first guess.
> 
> Removing the file is a bad idea!  Replacing it with the PyPI version
> (through debian/patches) is a much better approach.  (And possibly
> excluding the file in debian/copyright as well.)

Ah, scrap my comment - listen to Timo instead!

Best wishes,

   Julian

[toc] | [prev] | [next] | [standalone]

#14151 — Versioneer [was Re: a review of your bumblebee-status package]

[Multipart message — attachments visible in raw view] — view raw

Hi everyone,

* Ben Westover <kwestover.kw@gmail.com> [2022-06-06 22:42]:
>As far as I understand it, this file is used by the author of the 
>program, not end users. I don't understand it well, though, because I 
>haven't put much time into researching what versioneer even does.
Versioneer is meant to simplify version tracking for the developer;
it supports a number of authoritative sources such as "git
describe" to determine the current version number. There are two
modes of operation:

- in developer mode, versioneer detects the version number
   dynamically. This is what you'll see if you use the (Git)
   repository sources.
- in install mode, the release version number is statically
   embedded. This is what you'll see if
   you download from PyPI.

Internally, these modes are realized by two different _version.py
files; the developer version is usually added to version control,
and the setuptools "build" and "sdist" steps are
intercepted to insert the static _version.py as needed.

In my experience, it Just Works with pybuild, so I wouldn't bother
with any special treatment; the versioneer.py source is public
domain, so you're not going to run into any licensing issues.


Cheers
Timo


-- 
⢀⣴⠾⠻⢶⣦⠀   ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling                                       │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀   ╰────────────────────────────────────────────────────╯

[toc] | [prev] | [next] | [standalone]

#14160 — Re: Versioneer [was Re: a review of your bumblebee-status package]

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2022-06-07 at 16:12 +0200, Timo Röhling wrote:

> Versioneer is meant to simplify version tracking for the developer;
> it supports a number of authoritative sources such as "git
> describe" to determine the current version number. There are two
> modes of operation:
> 
> - in developer mode, versioneer detects the version number
>    dynamically. This is what you'll see if you use the (Git)
>    repository sources.
> - in install mode, the release version number is statically
>    embedded. This is what you'll see if
>    you download from PyPI.
> 
> Internally, these modes are realized by two different _version.py
> files; the developer version is usually added to version control,
> and the setuptools "build" and "sdist" steps are
> intercepted to insert the static _version.py as needed.

Personally I would not use the _version.py file from PyPI.

Sounds like the more correct thing to do is clone the GitHub repo,
check out the tag that Debian will use, run the build step, save the
generated _version.py file, add a patch containing that _version.py to
the Debian source package and generate an orig.tar from `git archive`.

Alternatively, upstream could switch from versioneer to flit-scm or
setuptools-scm, which both allow reporting the version number through
an environment variable, which IIRC pybuild does automatically.

Upstream should really drop the vendored versioneer either way though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web