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

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

Python Policy

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

Contents

  Python Policy Barry Warsaw <barry@debian.org> - 2015-10-19 19:40 +0200
    Re: Python Policy Scott Kitterman <debian@kitterman.com> - 2015-10-19 20:50 +0200
    Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-19 21:10 +0200
      Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-19 21:30 +0200
        Re: Python Policy Ben Finney <ben+debian@benfinney.id.au> - 2015-10-19 21:40 +0200
          Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-19 21:50 +0200
      Re: Python Policy Brian May <bam@debian.org> - 2015-10-20 00:30 +0200
        Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-20 00:40 +0200
          Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-20 16:50 +0200
            Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-20 17:10 +0200
      Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-20 16:40 +0200
        Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-20 17:00 +0200
    Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-19 23:30 +0200
      Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-20 16:30 +0200
        Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-20 17:20 +0200
          Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-20 22:20 +0200
      Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-20 23:00 +0200
        Re: Python Policy IOhannes m zmölnig (Debian/GNU)  <umlaeute@debian.org> - 2015-10-20 23:10 +0200
          Re: Python Policy Ben Finney <ben+debian@benfinney.id.au> - 2015-10-21 02:20 +0200
            Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-21 02:50 +0200
            Re: Python Policy IOhannes m zmölnig (Debian/GNU)  <umlaeute@debian.org> - 2015-10-21 10:00 +0200
              Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-21 16:00 +0200
                Re: Python Policy IOhannes m zmölnig (Debian/GNU)  <umlaeute@debian.org> - 2015-10-22 11:30 +0200
                  Re: DPMT Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-22 11:40 +0200
                    Re: DPMT Policy IOhannes m zmölnig (Debian/GNU)  <umlaeute@debian.org> - 2015-10-22 12:30 +0200
        Re: Python Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-20 23:40 +0200
          Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-21 03:00 +0200
            Re: Python Policy Vincent Bernat <bernat@debian.org> - 2015-10-21 10:40 +0200
              Re: Python Policy Brian May <brian@microcomaustralia.com.au> - 2015-10-21 11:50 +0200
                PyPI wheels (was Re: Python Policy) Barry Warsaw <barry@debian.org> - 2015-10-21 16:00 +0200
                  Re: PyPI wheels (was Re: Python Policy) Ian Cordasco <graffatcolmingov@gmail.com> - 2015-10-21 16:50 +0200
                    Re: PyPI wheels (was Re: Python Policy) Jeremy Stanley <fungi@yuggoth.org> - 2015-10-21 17:50 +0200
              Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-21 15:50 +0200
            Re: DPMT Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-21 14:10 +0200
              Re: DPMT Policy Barry Warsaw <barry@debian.org> - 2015-10-21 15:50 +0200
                Re: DPMT Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-21 16:20 +0200
                  Re: DPMT Policy Ben Finney <ben+debian@benfinney.id.au> - 2015-10-21 23:40 +0200
                    Re: DPMT Policy Barry Warsaw <barry@debian.org> - 2015-10-22 01:00 +0200
        Re: Python Policy IOhannes m zmölnig (Debian/GNU)  <umlaeute@debian.org> - 2015-10-22 11:20 +0200
          Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-23 01:40 +0200
        Re: Python Policy IOhannes m zmölnig (Debian/GNU)  <umlaeute@debian.org> - 2015-10-22 11:20 +0200
          Re: Python Policy Barry Warsaw <barry@debian.org> - 2015-10-23 01:40 +0200
    Re: DPMT Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-20 00:00 +0200
      Re: DPMT Policy Brian May <bam@debian.org> - 2015-10-20 00:30 +0200
      Re: DPMT Policy Barry Warsaw <barry@debian.org> - 2015-10-20 16:10 +0200
        Re: DPMT Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-20 17:10 +0200
          Re: DPMT Policy Piotr Ożarowski <piotr@debian.org> - 2015-10-20 23:40 +0200
    Re: Python Policy Brian May <bam@debian.org> - 2015-10-20 00:00 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#7731

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2015-10-21 02:17, Ben Finney wrote:
> "IOhannes m zmölnig (Debian/GNU)" <umlaeute@debian.org> writes:
> 
>> thanks a lot for preparing all this.
>> 
>> On 10/20/2015 10:53 PM, Barry Warsaw wrote:
>>> +DPMT requires upstream tarballs; releases cannot be made from
>>> upstream git +repositories directly.  This is because PyPI
>>> contains upstream tarballs, and +tarballs are what we upload to
>>> the Debian archive.
>> 
>> i find the justification a bit weird: "no releases can be made
>> from upstream git because some upstreams use tarballs"?
> 
> Yes, that is weird, and it's not what you quoted. I don't know how
> you get that meaning from the text you quoted

it's not what i quoted, but it's what i read in the quote.

it says "releases cannot be made from upstream git repositories
directly. This is because PyPI contains upstream tarballs [...]".

i fail to see what this "this" in the second sentence refers to if it
was not for the statement in the first sentence. thus creating a
cause-effect statement "pypi contains upstream tarballs -> releases
cannot be made from upstream git".
i think this logic is plain wrong.

for one thing, pypi - while being the most prominent source - is
probably *not* the only source for python modules. (that's why my
interpretation says "some upstreams").
furthermore, pypi is *not* upstream itself. it's a distribution
channel. an upstream (author) might as well do releases using git-tags
on github in addition to uploading the tarballs to pypi.
in this case, releases *can* (technically) be made from git tags.

it also says "[...] and tarballs are what we upload to the Debian
archive.".
which is true, but it's true for any Debian package (even those that
use upstream git or zip). so what's the point?


so: if my upstream does not use pypi (or i'm not aware of upstream
using pypi), does "tarballs required" policy still apply to me?

i think yes (but then i don't understand why there's a rationale if it
does not apply)


> This is because PyPI contains upstream tarballs, and tarballs are 
> what we upload to the Debian archive.
> 
>> in any case, i don't think that there is actually a need for the 
>> policy to justify the decision to require tarballs (let's put
>> that in the wiki for those interested).
> 
> On the contrary, I think the Policy document should document the 
> rationale for contingent decisions like this. When it is
> inevitably discussed again in the future, it is always better to
> know the intent of the authors.

that's why i said that the rationale should be documented in the wiki
(as opposed to the policy).
the policy did not contain a rationale why we chose svn.
the policy doesn't contain a rationale why we chose git.
(well, the decision for git will probably go unquestioned, but:)
the policy doesn't contain a rationale why we chose git-dpm (not even
a shallow one as "we need *a single* standard", let alone one that is
based on actual technical merits).


TL;DR

i am not a native speaker. so i might get things wrong.
but i'm not the only non-native English speaker in Debian.
therefore, i *strongly* suggest that the policy should be written in a
style that non-natives can understand it - without getting the
impression that considerable parts of the policy are only relevant for
specific setups (and not for them).

mfgsdr
IOhannes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWJ0P+AAoJELZQGcR/ejb4XtsQAIKQXQZxlzSgJF6zOi6NTgX8
Yq/y3mgvOZkWwsgOSqZKFVEnSsPQdBDptywSqV1Fm1Dy/6MS68jy03JRP+zWBUV1
n0Hr2NiMYzQxGBOhmIIrR7WtdEvxXhOs1Z1A3Nv5Tq4lJYX0XBPfAxOus/jdii6g
w84EIACtR6unvhGEcbABx8jNAecX73azN0Uni0S4BCYpczHgSEghulBu5FK4FT1M
22ZKA40S9kvq4naLg43A/hGjXsLvd//6Bfn5Cufu3YaAXugSaqIz16cNlzTKZDRq
F3NUtUtLD6RdjkCtzpAIo4WoUMZcvprXh34EVctj7uJ+tSYDi17J1dUO8HOTq3UI
EOEDFOscQvQZ+6h//89W6QjDdK8wW2C4jnspOQx6ZD4dJKa6r0qCKvBgx/E2fnmX
rb568XMXErGcjdLRAAyJj50UYud3uqNdRvjg6mrgQdRPghSFAQXz4jjx9W0y2bh8
MrC7BaaLA9nS3XdSMVwQWGMQJ4Nn+LTrWtBhnjLAEee1pWg5x4wdamLAPGKCyWN2
NYHweYdcGuEAeoYr5T9tpEsnRZQo6kIE+jRKp0IX88JGLqdv1eyy+/gk+mYtSkTY
Qie0dvzTUs4btwI3To1g2X6oCRaBMabm0sZ4/yLZBqpSC9NdrB3YAsBRX3xWMgEg
2DCyuPCVFKHWUp1Pz++T
=sKPF
-----END PGP SIGNATURE-----

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

#7737

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

On Oct 21, 2015, at 09:51 AM, IOhannes m zmölnig (Debian/GNU) wrote:

>i am not a native speaker. so i might get things wrong.
>but i'm not the only non-native English speaker in Debian.
>therefore, i *strongly* suggest that the policy should be written in a
>style that non-natives can understand it - without getting the
>impression that considerable parts of the policy are only relevant for
>specific setups (and not for them).

I'm a native English speaker and I completely agree.  Thanks for pointing out
instances where the wording is unclear.  Hopefully, the latest changes (see
previous follow up) are both more concise and coherent.

Cheers,
-Barry

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

#7755

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2015-10-21 15:54, Barry Warsaw wrote:
> Hopefully, the latest changes (see previous follow up) are both
> more concise and coherent.

maybe.

i have to admit i'm not totally used to an reviewing git patches per
mailinglists, and in this case i got lost a little bit what the
current draft is.
would it be possible to put a complete draft online somewhere (maybe
even as an r/o git), in addition to posting the patches on the ml.

fg,asdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWKKtpAAoJELZQGcR/ejb4IAoP/iawsZNZApH4TsalsLOUe2I5
HVO9N0/KpmiJZtHWLdj0kfzbdiffb7GCcpDggZgzX3sZiWzQgMJAprqi8zX66hqR
txIIPMDehm/QrxS7Gc1Ul6X/hpiaB/j4ROHjzzHoWrNsyXPaOCrOJ/I6nEwCh5Qb
BGnHkYbIYd1yqJzkPVcGRedwrWcsjOh4AiodxQMk8TDxnz/dcjc2BBQqx0cyCAIX
GW4P3RE0Tzf/K0327eQgA3hUTZnCB4IBHl1Z4Fo6Eb24MjuU0eE2LY1nOFXOwqYX
hwTNZ40X/yBjj9YI3rBNYb7Z+PThKWnP4dBHtaBUNfVeb0X+8MOlmB03RW5oVKA4
DmOCOEBWngCTcybXV7xsmyXkfa8ZxK/WE98nfNhVX2kVc5O3DAiiTAwpKTTqzLL4
3wUtbT/F7cPmju6GwyU3BVt/edazpzd6ovGJc7KVdqaDJ5YNvf1KPQNcO0PevMwF
wArJD7JH3+qdd5dpTaZYJY+Ej1SBDkKT0BYtJa2H5EsU7OVZ+XBh39lqmtzUWPIY
On1NfhmfuMQ1Zl0P1woOVvXtFv8AJQEY2uVmNzP50dyKq+4qLmFNNmocWEf3QI2I
emp16RgczBi6eiJbu+1xnGlhv3ygi4coH/QiWzgIvtjp3PmvTXBZThtrXdwQ3QMa
PX8qDp/tQqEk/MNMRpSl
=u0vU
-----END PGP SIGNATURE-----

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

#7756 — Re: DPMT Policy

> i have to admit i'm not totally used to an reviewing git patches per
> mailinglists, and in this case i got lost a little bit what the
> current draft is.
> would it be possible to put a complete draft online somewhere (maybe
> even as an r/o git), in addition to posting the patches on the ml.

git clone git://anonscm.debian.org/python-modules/tools/python-modules.git -b git-policy barry-policy && less barry-policy/policy.rst
or
http://anonscm.debian.org/cgit/python-modules/tools/python-modules.git/tree/policy.rst?h=git-policy

-- 
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

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

#7757 — Re: DPMT Policy

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2015-10-22 11:30, Piotr Ożarowski wrote:
>> i have to admit i'm not totally used to an reviewing git patches
>> per mailinglists, and in this case i got lost a little bit what
>> the current draft is. would it be possible to put a complete
>> draft online somewhere (maybe even as an r/o git), in addition to
>> posting the patches on the ml.
> 
> git clone
> git://anonscm.debian.org/python-modules/tools/python-modules.git -b
> git-policy barry-policy && less barry-policy/policy.rst or 
> http://anonscm.debian.org/cgit/python-modules/tools/python-modules.git
/tree/policy.rst?h=git-policy
>
> 
doh, thanks.
(i actually had the repo cloned already but failed to see the
`git-policy` branch :-()

fgamsdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWKLhhAAoJELZQGcR/ejb4kDcP/ArjYABIju910SROwY1PUtd4
HQhYlUHW+7V+DlsK7rVRgBJGrHXWAVDq0ySOl5e/15jixwxgsezAOK0jDv7bjvsW
pYJX3wRR88TiQqKNhaka0S4LiHm/3cdeISk7mnzKEOGsgD+7+KNVvAWrfVTeFuD2
8jCF8rPBODEAckyC0PblykONstQc9NMvYx7TnlcSb/xWWAiUQFvxEu+ZEFtU5VqZ
rP4L3MN2fdZemwVeAEzIImnlZTL9l9h0J0+6czTMa8oR3hWlS+Ef+7mmKLusJitR
Rmg14gmge+R0RBtlvHVk328grGZAxOYXWhNf8xOOt1IutCEqU8421GLUbGJF340W
sDyQ8YKisYbqqrdQUDf65zwMAxXMxa/2u2Zm36Gxt46c6gD+wtzlGBtqfrWVHjyz
SlbdlwTMu7N14vXmUCAvdp7qRuw20YbyVkkqTJNqWyIcX7Il0WlqwqOHMOh0wtY4
cApGAjeRvILXLlTbRs34lj4OTwFJvJTkbp3QLw8XM8hO84ZfPENKRtYv6r6vnrpw
EefCdJ9FrH7kRI0m3AHIvDHnUnLDECp9sAY2ijPskBGj7AE2akCU1sVMy1eaBBtE
J9eh74UYyuPLJFL4xKG+2N56Ju4joV8JnSL2EKBPxrr0jnSNbUCwojAk/sFD/ill
rD0t0urXQ97b+JmFhpdT
=bH0k
-----END PGP SIGNATURE-----

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

#7725

[Barry Warsaw, 2015-10-20]
> Latest diff against master.  If you're happy with this, I'll merge to master,
> update the web page, and trim the wiki.

I have few comments, but even if I didn't, please wait at least until after
the weekend (or better: 7 days) so that others have time to review it and
comment / propose changes.

I removed everything that sounds fine to me.

> +DPMT requires upstream tarballs; releases cannot be made from upstream git
> +repositories directly.  This is because PyPI contains upstream tarballs, and
> +tarballs are what we upload to the Debian archive.

I'd remove this paragraph. Releases can be made via `git archive` and I
did that many times (assuming pristine-tar will still keep needed data
to regenerate exact same tarball).
If you meant that we don't want to keep complete upstream git history,
then I agree completely, but I'd made it a "should" rather than "must".

> +``gbp build-package`` is used to build the package, either as a source package

s/build-package/buildpackage/

> +for use with ``pbuilder``, ``sbuild``, etc. or as a binary package directory.

gbp can use sbuild/pbuilder, here's my ~/.gbp.conf:

  [buildpackage]
  builder=sbuild

> +Use the following ``git-dpm`` tag formats for the three branches named above.
> +Put these lines at the *end* of your ``debian/.git-dpm`` file::
> +
> +    debianTag="debian/%e%v"
> +    patchedTag="patches/%e%v"
> +    upstreamTag="upstream/%e%u"

I will update `py2dsp --profile dpmt ...` to do that out of the box, but
even then, it's better to suggest that tool in the wiki only, I guess

> +All packages which have been automatically converted from the old Subversion
> +repository should already have these lines present, but you will need to add
> +them for any new packages.

that's something for the wiki, not policy, IMO


other comment:
I'm wondering about something that bit me recently: `gbp pull` instead
of `git pull` - should we put that into policy or is wiki warning enough?
-- 
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

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

#7728

On Oct 20, 2015, at 11:30 PM, Piotr Ożarowski wrote:

>I have few comments, but even if I didn't, please wait at least until after
>the weekend (or better: 7 days) so that others have time to review it and
>comment / propose changes.

Fair enough.  Of course, it's in a vcs so it's easy to change! :)

>I'd remove this paragraph. Releases can be made via `git archive` and I did
>that many times (assuming pristine-tar will still keep needed data to
>regenerate exact same tarball).  If you meant that we don't want to keep
>complete upstream git history, then I agree completely, but I'd made it a
>"should" rather than "must".

What I'm trying to express is the team decision (a couple of debconfs ago) for
pristine-tars rather than releasing from upstream git.  I do want to keep the
rationale in the policy doc; it's one sentence and it seems to come up often
enough.  Suggestions for better phrasing welcome!

>> +``gbp build-package`` is used to build the package, either as a source
>> package
>
>s/build-package/buildpackage/

Fixed, thanks.

>> +for use with ``pbuilder``, ``sbuild``, etc. or as a binary package directory.
>
>gbp can use sbuild/pbuilder, here's my ~/.gbp.conf:
>
>  [buildpackage]
>  builder=sbuild

This is the kind of thing that should go in the wiki.

>> +Use the following ``git-dpm`` tag formats for the three branches named above.
>> +Put these lines at the *end* of your ``debian/.git-dpm`` file::
>> +
>> +    debianTag="debian/%e%v"
>> +    patchedTag="patches/%e%v"
>> +    upstreamTag="upstream/%e%u"
>
>I will update `py2dsp --profile dpmt ...` to do that out of the box, but
>even then, it's better to suggest that tool in the wiki only, I guess

I think so.  The tag format (and IMHO the mechanism to ensure it) should go in
policy though.

>> +All packages which have been automatically converted from the old
>> Subversion +repository should already have these lines present, but you
>> will need to add +them for any new packages.
>
>that's something for the wiki, not policy, IMO

Sure.  I reworded the policy docs a little bit here.

>other comment:
>I'm wondering about something that bit me recently: `gbp pull` instead
>of `git pull` - should we put that into policy or is wiki warning enough?

I think wiki is enough.  It is possible to operate with just straight `git
pull` because it will still fetch all commits, but when you switch to one of
the other branches, you'll see that its head is out of date, and git will
prompt you to pull in that branch to update it.  `gbp pull` is mostly
convenience.

Cheers,
-Barry

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

#7732

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

 ❦ 20 octobre 2015 20:52 -0400, Barry Warsaw <barry@debian.org> :

>>I'd remove this paragraph. Releases can be made via `git archive` and I did
>>that many times (assuming pristine-tar will still keep needed data to
>>regenerate exact same tarball).  If you meant that we don't want to keep
>>complete upstream git history, then I agree completely, but I'd made it a
>>"should" rather than "must".
>
> What I'm trying to express is the team decision (a couple of debconfs ago) for
> pristine-tars rather than releasing from upstream git.  I do want to keep the
> rationale in the policy doc; it's one sentence and it seems to come up often
> enough.  Suggestions for better phrasing welcome!

You should remove the reference to Pypi since tarballs can also be taken
From GitHub (when upstream doesn't want to ship everything, like tests,
in Pypi tarballs or doesn't even release tarballs on Pypi):

> DPMT requires upstream tarballs, either released on PyPI (or any other
> place) or snapshots made from git. Tarballs are what we upload to the
> Debian archive.
-- 
Use recursive procedures for recursively-defined data structures.
            - The Elements of Programming Style (Kernighan & Plauger)

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

#7733

Vincent Bernat <bernat@debian.org> writes:

> You should remove the reference to Pypi since tarballs can also be taken
> From GitHub (when upstream doesn't want to ship everything, like tests,
> in Pypi tarballs or doesn't even release tarballs on Pypi):

Have filled upstream bugs on issues that prevent me using the Pypi
source - in one case this is because upstream have only supplied a *.whl
file on Pypi. Don't expect upstream to fix them anytime soon however. So
far no response. The projects aren't very active.

https://github.com/mbi/django-simple-captcha/issues/94
https://github.com/bradleyayers/django-tables2/issues/267

I probably will end up using github source - and I suspect that is what
I have done in the past - debian/watch points to Pypi - something else I
will need to fix too, I guess.
-- 
Brian May <brian@microcomaustralia.com.au>

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

#7738 — PyPI wheels (was Re: Python Policy)

On Oct 21, 2015, at 08:47 PM, Brian May wrote:

>in one case this is because upstream have only supplied a *.whl
>file on Pypi.

I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads.
There is talk about source wheels, and if that happens we'll probably have to
adjust our tools to handle them, but in theory they shouldn't be that much
different than being able to handle a different compression or encapsulation
format.

Cheers,
-Barry

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

#7740 — Re: PyPI wheels (was Re: Python Policy)

On Wed, Oct 21, 2015 at 8:58 AM, Barry Warsaw <barry@debian.org> wrote:
> On Oct 21, 2015, at 08:47 PM, Brian May wrote:
>
>>in one case this is because upstream have only supplied a *.whl
>>file on Pypi.
>
> I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads.

I'm not sure why they should prohibit binary wheel-only uploads. A
company may wish to publish a binary wheel of a tool and only that (a
wheel for Windows, OS X, different supported linux distributions,
etc.). If they do, that's their prerogative. I don't think there's
anything that says Debian (or Ubuntu) would then have to package that.

PyPI is not just there for downstream, it's there for users too
(although the usability of PyPI is not exactly ideal).

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

#7742 — Re: PyPI wheels (was Re: Python Policy)

On 2015-10-21 09:31:04 -0500 (-0500), Ian Cordasco wrote:
> On Wed, Oct 21, 2015 at 8:58 AM, Barry Warsaw <barry@debian.org> wrote:
> > On Oct 21, 2015, at 08:47 PM, Brian May wrote:
> >
> >>in one case this is because upstream have only supplied a *.whl
> >>file on Pypi.
> >
> > I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads.
> 
> I'm not sure why they should prohibit binary wheel-only uploads. A
> company may wish to publish a binary wheel of a tool and only that (a
> wheel for Windows, OS X, different supported linux distributions,
> etc.). If they do, that's their prerogative. I don't think there's
> anything that says Debian (or Ubuntu) would then have to package that.
> 
> PyPI is not just there for downstream, it's there for users too
> (although the usability of PyPI is not exactly ideal).

Yep, I'm as much a fan of free software as the next person, but PyPI
doesn't _require_ what you upload is free software. It only requires
that you grant the right to redistribute what you're uploading.
While having source code to go along with things uploaded there
(which, mind you, aren't even actually required to be usable python
packages, they could be just about anything) would be nice, I don't
have any expectation that PyPI would ever eventually make it
mandatory.
-- 
Jeremy Stanley

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

#7735

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

On Oct 21, 2015, at 08:46 AM, Vincent Bernat wrote:

>You should remove the reference to Pypi since tarballs can also be taken
>From GitHub (when upstream doesn't want to ship everything, like tests,
>in Pypi tarballs or doesn't even release tarballs on Pypi):

Yep, done.

-Barry

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

#7734 — Re: DPMT Policy

[Barry Warsaw, 2015-10-21]
> What I'm trying to express is the team decision (a couple of debconfs ago) for
> pristine-tars rather than releasing from upstream git.  I do want to keep the
> rationale in the policy doc; it's one sentence and it seems to come up often
> enough.  Suggestions for better phrasing welcome!

Only version to version upstream changes should be kept in the repository -
complete upstream git history should be avoided. In order to make it
easier to cherry-pick upstream commits as patches, add remote repository
(example below).
 
  git remote add upstream_repo git://example.com/foo.git
  git fetch upstream_repo
  git-dpm checkout-patched
  git cherry-pick any_upstream_commit
  git-dpm update-patches

> >> +for use with ``pbuilder``, ``sbuild``, etc. or as a binary package directory.
> >
> >gbp can use sbuild/pbuilder, here's my ~/.gbp.conf:
> >
> >  [buildpackage]
> >  builder=sbuild
> 
> This is the kind of thing that should go in the wiki.
> 

I simply suggest to:

s/, either as a source package for use with ``pbuilder``, ``sbuild``, etc. or as a binary package directory/ (it can be configured to use sbuild, pbuilder, etc.)/

or remove this part completely

> >> +Use the following ``git-dpm`` tag formats for the three branches named above.
> >> +Put these lines at the *end* of your ``debian/.git-dpm`` file::
> >> +
> >> +    debianTag="debian/%e%v"
> >> +    patchedTag="patches/%e%v"
> >> +    upstreamTag="upstream/%e%u"
> >
> >I will update `py2dsp --profile dpmt ...` to do that out of the box, but
> >even then, it's better to suggest that tool in the wiki only, I guess
> 
> I think so.  The tag format (and IMHO the mechanism to ensure it) should go in
> policy though.

nothing against this paragraph, just wanted to state that wiki will not have
to mention it if we have a tool that configures new package the way policy wants.

> >I'm wondering about something that bit me recently: `gbp pull` instead
> >of `git pull` - should we put that into policy or is wiki warning enough?
> 
> I think wiki is enough. It is possible to operate with just straight `git
> pull` because it will still fetch all commits, but when you switch to one of
> the other branches, you'll see that its head is out of date, and git will
> prompt you to pull in that branch to update it.  `gbp pull` is mostly
> convenience.

gbp buildpackage will fail if you never switched to pristine-tar (and
git didn't warn you about new commits). It wasn't obvious to me why
it fails when it hit me for the first time.
-- 
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

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

#7736 — Re: DPMT Policy

On Oct 21, 2015, at 02:06 PM, Piotr Ożarowski wrote:

>Only version to version upstream changes should be kept in the repository -
>complete upstream git history should be avoided. In order to make it
>easier to cherry-pick upstream commits as patches, add remote repository
>(example below).
> 
>  git remote add upstream_repo git://example.com/foo.git
>  git fetch upstream_repo
>  git-dpm checkout-patched
>  git cherry-pick any_upstream_commit
>  git-dpm update-patches

How about this:

"""
DPMT requires a pristine-tar branch, and only upstream tarballs can be used to
advance the upstream branch.  Complete upstream git history should be avoided
in the upstream branch.
"""

I like the cherry picking advice, so I added that to the wiki.

>I simply suggest to:
>
>s/, either as a source package for use with ``pbuilder``, ``sbuild``, etc. or as a binary package directory/ (it can be configured to use sbuild, pbuilder, etc.)/
>
>or remove this part completely

I removed the sentence about gbp.  That's a local decision so it doesn't need
to go in policy.

>nothing against this paragraph, just wanted to state that wiki will not have
>to mention it if we have a tool that configures new package the way policy
>wants.

+1

>> >I'm wondering about something that bit me recently: `gbp pull` instead
>> >of `git pull` - should we put that into policy or is wiki warning enough?
>> 
>> I think wiki is enough. It is possible to operate with just straight `git
>> pull` because it will still fetch all commits, but when you switch to one of
>> the other branches, you'll see that its head is out of date, and git will
>> prompt you to pull in that branch to update it.  `gbp pull` is mostly
>> convenience.
>
>gbp buildpackage will fail if you never switched to pristine-tar (and
>git didn't warn you about new commits). It wasn't obvious to me why
>it fails when it hit me for the first time.

Yep.  Again though, since this is a local decision, it should go in the wiki.

Cheers,
-Barry

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

#7739 — Re: DPMT Policy

[Barry Warsaw, 2015-10-21]
> How about this:
> 
> """
> DPMT requires a pristine-tar branch, and only upstream tarballs can be used to
> advance the upstream branch.  Complete upstream git history should be avoided
> in the upstream branch.
> """

just a tiny change: s/  / /
-- 
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

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

#7744 — Re: DPMT Policy

Piotr Ożarowski <piotr@debian.org> writes:

> [Barry Warsaw, 2015-10-21]
> > """
> > DPMT requires a pristine-tar branch, and only upstream tarballs can be used to
> > advance the upstream branch.  Complete upstream git history should be avoided
> > in the upstream branch.
> > """
>
> just a tiny change: s/  / /

+1 <URL:http://www.slate.com/articles/technology/technology/2011/01/space_invaders.html>

-- 
 \          “The entertainment industry calls DRM "security" software, |
  `\         because it makes them secure from their customers.” —Cory |
_o__)                                             Doctorow, 2014-02-05 |
Ben Finney

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

#7747 — Re: DPMT Policy

On Oct 22, 2015, at 08:32 AM, Ben Finney wrote:

>+1 <URL:http://www.slate.com/articles/technology/technology/2011/01/space_invaders.html>

GOML
-Barry

:)

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

#7753

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2015-10-20 22:53, Barry Warsaw wrote:
> +Any·Debian·developer·who·wishes·to·integrate·his·packages·in·the·team
·can·do
>
> 
+so·without·requesting·access·(as·the·repository·is·writable·by·all·DD).
·If·one
> wants·to·be·more·involved·in·the·team,·we·still·recommend·requesting_·
access

that's
> 
something else i wonder whether we shouldn't drop it, as i
don't quite understand why it has to be in the policy.

i *think* it's supposed to urge DDs into becoming team members, even
though they can ("are able to") already write to the repos without
asking for permissions.
but in fact for me it conveys the complete opposite: DDs can ("are
welcome to") add stuff to the repo, and they should only "request" if
they want to commit themselves to the team.

...which is probably a (not so) good loophole for any DD who just want
their python packages under the DMPT umbrella without getting too
involved (e.g. no sponsoring, maybe not even obey the the policy,...) :-
(

fgmasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWKKg0AAoJELZQGcR/ejb4GjAP/iTM+RxdQhuS9UqqnsMfLp36
f8BRMHoNm8CBnDBoWoYHGnSc3VshnL2Tzea2aSawW3KKcvf0b4/Hvta3gcqg/OHt
QHeNEJX+PPgJqo/5m+k+jbdB4QeIy5zGwcCxcLnhCdY53x1bCrQMytaMYZy3K+Qy
8eO/wRmKJHBlnoH1DF7KIBwj78bS/rmcHcCw16YzN2RuQQwpBaPwz9HmlkAK4TY/
QqjS9s7Hm80zD5VdzYsIluBoLgaIrbPfaL81YGpY98I56nVGcWd1FhP5BaRlmxyV
LDRPH7CT+AfEmUqAVKnuUWkEAKKz8vzA2imE+QTlrfZ3GAXZUgTw9FEazO9F4Asq
j+b6nSlwyt+B5iLjbjdtMtNTaZdA/OD4jwYt8DfT/aLDrgKcL1byjGjmIzSGIrS+
tX44kJSqN7Bo84Ax7rXRVfC0iAqXQiu/yNQb11dQhXjPGZuREKEXz2WS4zxM7e8Z
GAi3MT41s2zqtSxyU2u8tsV02YreI4shjPpw2PHE11xvy17rFXn678QxXS9iCxr0
tWRLWxLhxHD41UDip+Ir01UWF7LATMpBKVt34ZPUukytLCf109vmEzcX3EoiYXIT
JuYa11KYfGsHI5VkHt3JhraNfprSe/TlGQ+1V899rijpkrftlFgp2iBUi21yPxGB
ET79wfUpZkH3r5u8dHb8
=aAVW
-----END PGP SIGNATURE-----

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

#7764

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

On Oct 22, 2015, at 11:11 AM, IOhannes m zmölnig (Debian/GNU) wrote:

>something else i wonder whether we shouldn't drop it, as i don't quite
>understand why it has to be in the policy.
>
>i *think* it's supposed to urge DDs into becoming team members, even though
>they can ("are able to") already write to the repos without asking for
>permissions.  but in fact for me it conveys the complete opposite: DDs can
>("are welcome to") add stuff to the repo, and they should only "request" if
>they want to commit themselves to the team.
>
>...which is probably a (not so) good loophole for any DD who just want their
>python packages under the DMPT umbrella without getting too involved (e.g. no
>sponsoring, maybe not even obey the the policy,...) :- (

Ultimately it reflects reality given that we won't (can't?) prohibit DDs from
write access without joining the team.

For example, if an NMU gets uploaded, I'd like for the DD to be able to commit
the change to the repo directly rather than have ask us one of us to do it for
them.  But any DD who really cares about Python should join the team, IMHO.
It's a pretty low barrier.

Cheers,
-Barry

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web