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


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

pep8 renamed to pycodestyle

Started byBarry Warsaw <barry@debian.org>
First post2016-06-20 22:00 +0200
Last post2016-08-09 23:30 +0200
Articles 9 — 5 participants

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


Contents

  pep8 renamed to pycodestyle Barry Warsaw <barry@debian.org> - 2016-06-20 22:00 +0200
    Re: pep8 renamed to pycodestyle Ben Finney <ben+debian@benfinney.id.au> - 2016-06-21 03:40 +0200
      Re: pep8 renamed to pycodestyle Thomas Goirand <zigo@debian.org> - 2016-06-21 22:00 +0200
    Re: pep8 renamed to pycodestyle Piotr Ożarowski <piotr@debian.org> - 2016-06-21 10:20 +0200
      Re: pep8 renamed to pycodestyle Barry Warsaw <barry@debian.org> - 2016-06-21 13:50 +0200
        Re: pep8 renamed to pycodestyle Ondrej Novy <novy@ondrej.org> - 2016-08-08 01:10 +0200
          Re: pep8 renamed to pycodestyle Barry Warsaw <barry@debian.org> - 2016-08-08 01:40 +0200
            Re: pep8 renamed to pycodestyle Ondrej Novy <novy@ondrej.org> - 2016-08-08 12:10 +0200
              Re: pep8 renamed to pycodestyle Barry Warsaw <barry@debian.org> - 2016-08-09 23:30 +0200

#8597 — pep8 renamed to pycodestyle

FromBarry Warsaw <barry@debian.org>
Date2016-06-20 22:00 +0200
Subjectpep8 renamed to pycodestyle
Message-ID<rMdwt-44L-29@gated-at.bofh.it>

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

You might be aware that the upstream pep8 package has been renamed to
pycodestyle.  Both the command line and imports have changed, although not in
a backward compatible way unfortunately[1].

There's a new upstream flake8 which I'm preparing in git-dpm, but it will be
blocked until we decide what to do about the Debian pep8 package.

I think we eventually want to rename Source:pep8 to Source:pycodestyle, as
well as Package:pep8, Package:python-pep8, and Package:python3-pep8.  I
suppose we could at least keep the source package name unchanged and
transition to the new binary package names.

I'd like to add some backward compatibility hacks, either our own or
upstreams, for the name change.  See the referenced issues.

Looking for any thoughts, comments, or suggestions.  I also don't want to step
on any toes if someone's already starting this transition.  There are some
reverse dependencies, but not too many I think so it should be fairly easy to
just upload new packages (if available; I haven't checked them all).

Cheers,
-Barry

[1] https://github.com/PyCQA/pycodestyle/issues/544
    https://github.com/PyCQA/pycodestyle/issues/549

[toc] | [next] | [standalone]


#8598

FromBen Finney <ben+debian@benfinney.id.au>
Date2016-06-21 03:40 +0200
Message-ID<rMiPv-7uu-7@gated-at.bofh.it>
In reply to#8597
Barry Warsaw <barry@debian.org> writes:

> You might be aware that the upstream pep8 package has been renamed to
> pycodestyle. Both the command line and imports have changed, although
> not in a backward compatible way unfortunately[1].

Ah, Python. We love you, but please grow a proper API versioning system :-/

> There's a new upstream flake8 which I'm preparing in git-dpm, but it
> will be blocked until we decide what to do about the Debian pep8
> package.

(I hope the upstream ‘flake8’ now defaults to conforming with PEP 8,
instead of having default checks that contradict it.)

> I think we eventually want to rename Source:pep8 to
> Source:pycodestyle, as well as Package:pep8, Package:python-pep8, and
> Package:python3-pep8. I suppose we could at least keep the source
> package name unchanged and transition to the new binary package names.

My understanding is that renaming a source package is rather more
disruptive than renaming a binary package, is that right?

If so, I would recommend:

* Go ahead and transition the binary package names with the usual
  mechanisms <URL:https://wiki.debian.org/PackageTransition>:

  * Keep the old names as a transition package until after
    Debian Stretch is released.

  * Have the new binary packages declare Replaces and Conflicts
    relationships with the appropriate version specification of the old
    names.

  * Maybe even schedule the transition with the release team
    <URL:https://wiki.debian.org/Teams/ReleaseTeam/Transitions>, to
    allow co-ordination of dependent packages.

* Since you've determined the command-line interfaces are not
  compatible, the new commands should not be alternatives for the old.

* As a separate matter, figure out how best to rename the source package
  to better correspond with the new name upstream. This could take an
  arbitrarily long time; IMO while it is desirable to rename the source
  package, there's no tearing need yet.

-- 
 \       “Come on, if your religion is so vulnerable that a little bit |
  `\           of disrespect is going to bring it down, it's not worth |
_o__)               believing in, frankly.” —Terry Gilliam, 2005-01-18 |
Ben Finney

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


#8601

FromThomas Goirand <zigo@debian.org>
Date2016-06-21 22:00 +0200
Message-ID<rMA01-1Ki-1@gated-at.bofh.it>
In reply to#8598
On 06/21/2016 03:35 AM, Ben Finney wrote:
> My understanding is that renaming a source package is rather more
> disruptive than renaming a binary package, is that right?

To my experience, renaming a source package is painless. The pain used
to be for FTP masters, but now even that is automated nowadays (with
their "clean cruft" script, whatever they called it...). I did rename
source packages like oslo-config -> python-oslo.config and
oslo.messaging -> python-oslo.messaging, just for the sake of
consistency. It was no problem at all, and when I contacted FTP masters,
they told me that nobody had anything to do to deal with it.

>   * Maybe even schedule the transition with the release team

We don't have enough of these in Python. More often than not, disruptive
uploads aren't coordinated, and it breaks the world.

Though in this case, since Barry is proposing hacks to support both
names (thanks, that's very much welcome!). So it will be smooth, and we
can slowly open, then close bugs, slowly.

Cheers,

Thomas Goirand (zigo)

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


#8599

FromPiotr Ożarowski <piotr@debian.org>
Date2016-06-21 10:20 +0200
Message-ID<rMp4B-3gc-17@gated-at.bofh.it>
In reply to#8597
[Barry Warsaw, 2016-06-20]
> I think we eventually want to rename Source:pep8 to Source:pycodestyle, as
> well as Package:pep8, Package:python-pep8, and Package:python3-pep8.  I
> suppose we could at least keep the source package name unchanged and
> transition to the new binary package names.

I'd simply create new source package with new binary packages and remove
src:pep8 even from Stretch (once all rev. dependencies use new package).
-- 
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]


#8600

FromBarry Warsaw <barry@debian.org>
Date2016-06-21 13:50 +0200
Message-ID<rMslP-5hj-5@gated-at.bofh.it>
In reply to#8599
On Jun 21, 2016, at 10:18 AM, Piotr Ożarowski wrote:

>I'd simply create new source package with new binary packages and remove
>src:pep8 even from Stretch (once all rev. dependencies use new package).

Yep, I'm leaning toward this, or at least creating a new source package for
pycodestyle.  I think there are enough backward compatibility concerns that we
should leave it to reverse-dependencies to make the switch.  Whether or not we
remove pep8 from Stretch is a separate decision, but I'd be okay with that
if/when all the revdeps get ported over.

Cheers,
-Barry

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


#8711

FromOndrej Novy <novy@ondrej.org>
Date2016-08-08 01:10 +0200
Message-ID<s3FmF-1M0-1@gated-at.bofh.it>
In reply to#8600

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

Hi,

2016-06-21 13:43 GMT+02:00 Barry Warsaw <barry@debian.org>:

> >I'd simply create new source package with new binary packages and remove
> >src:pep8 even from Stretch (once all rev. dependencies use new package).
>

created (https://bugs.debian.org/833683) and uploaded :)

-- 
Best regards
 Ondřej Nový

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


#8712

FromBarry Warsaw <barry@debian.org>
Date2016-08-08 01:40 +0200
Message-ID<s3FPI-1Xa-7@gated-at.bofh.it>
In reply to#8711

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

On Aug 08, 2016, at 12:52 AM, Ondrej Novy wrote:

>created (https://bugs.debian.org/833683) and uploaded :)

\o/

Thanks,
-Barry

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


#8714

FromOndrej Novy <novy@ondrej.org>
Date2016-08-08 12:10 +0200
Message-ID<s3PFn-8rE-1@gated-at.bofh.it>
In reply to#8712

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

Hi,

what do you think about this:
https://anonscm.debian.org/cgit/python-modules/packages/pep8.git/commit/?id=655e6f631fc854c51f48f142e58bdb6b4af8494f

With this change we can make slow transition pep8 -> pycodestyle without
breaking current pep8 users.

BTW: pycodestyle is still in NEW, so don't upload :)

Thanks.

-- 
Best regards
 Ondřej Nový

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


#8725

FromBarry Warsaw <barry@debian.org>
Date2016-08-09 23:30 +0200
Message-ID<s4mKZ-4uz-15@gated-at.bofh.it>
In reply to#8714

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

Hi Ondrej,

On Aug 08, 2016, at 11:46 AM, Ondrej Novy wrote:

>what do you think about this:
>https://anonscm.debian.org/cgit/python-modules/packages/pep8.git/commit/?id=655e6f631fc854c51f48f142e58bdb6b4af8494f
>
>With this change we can make slow transition pep8 -> pycodestyle without
>breaking current pep8 users.

It seems reasonable to me.  We definitely want to keep the pep8 script and
libraries alive for a while so other packages can catch up.  There's also some
discussion of this upstream:

https://github.com/PyCQA/pycodestyle/issues/544

I think we don't need to wait for upstream to decide though, so +1 on your
changes.

>BTW: pycodestyle is still in NEW, so don't upload :)

I'll leave that to you! :)

Thanks,
-Barry

[toc] | [prev] | [standalone]


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


csiph-web