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

Groups > comp.lang.python > #90473 > unrolled thread

Updating a package on PyPi, testing and etiquette

Back to article view | Back to comp.lang.python

Contents

  Updating a package on PyPi, testing and etiquette Rob Gaddi <rgaddi@technologyhighland.invalid> - 2015-05-12 18:01 +0000
    Re: Updating a package on PyPi, testing and etiquette Ned Batchelder <ned@nedbatchelder.com> - 2015-05-12 11:18 -0700
      Re: Updating a package on PyPi, testing and etiquette Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-13 12:17 +1000
    Re: Updating a package on PyPi, testing and etiquette Ben Finney <ben+python@benfinney.id.au> - 2015-05-13 08:35 +1000
      Re: Updating a package on PyPi, testing and etiquette Rob Gaddi <rgaddi@technologyhighland.invalid> - 2015-05-12 23:54 +0000
        Re: Updating a package on PyPi, testing and etiquette Ben Finney <ben+python@benfinney.id.au> - 2015-05-13 10:08 +1000

#90473 — Updating a package on PyPi, testing and etiquette

So I've got a package I put up on PyPi a while back (ctypes-bitfield, if 
it matters).  For version 0.2.6 I had access to some older versions of 
Python and was able to run my test suite on Python 2.6 and 3.0.

Well, I don't have them anymore.  I've got no access right now to 
anything older than 2.7 and 3.2, and my primary development environment 
is 3.4.  But I've also updated the package to support what I consider to 
be some really nice new functionality.  So, it comes down to two 
questions:

A) Is there any easy way to test against an older version of Python?  
Preferably without trying to install entire old environments and keep 
them nicely isolated from my actual doing work?  I'm running Ubuntu for 
what difference that makes.

B) If I can't manage that, what's the etiquette behind having later 
versions of a module break compatibility with older versions of Python.  
I've avoided using features I know are newer, like yield from and Enums, 
but I won't swear it'll work on 3.0 if I can't test it that way.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

[toc] | [next] | [standalone]

#90475

On Tuesday, May 12, 2015 at 2:03:04 PM UTC-4, Rob Gaddi wrote:
> So I've got a package I put up on PyPi a while back (ctypes-bitfield, if 
> it matters).  For version 0.2.6 I had access to some older versions of 
> Python and was able to run my test suite on Python 2.6 and 3.0.
> 
> Well, I don't have them anymore.  I've got no access right now to 
> anything older than 2.7 and 3.2, and my primary development environment 
> is 3.4.  But I've also updated the package to support what I consider to 
> be some really nice new functionality.  So, it comes down to two 
> questions:
> 
> A) Is there any easy way to test against an older version of Python?  
> Preferably without trying to install entire old environments and keep 
> them nicely isolated from my actual doing work?  I'm running Ubuntu for 
> what difference that makes.

I've used pythonz (http://saghul.github.io/pythonz/) to install a
variety of Python versions.  It works really well for me.

> 
> B) If I can't manage that, what's the etiquette behind having later 
> versions of a module break compatibility with older versions of Python.  
> I've avoided using features I know are newer, like yield from and Enums, 
> but I won't swear it'll work on 3.0 if I can't test it that way.

No one supports 3.0 any more.  3.2 is kind of the oldest version
that is still reasonable, and many people are only aiming for 3.3
and 3.4.

Just because you are supporting 2.7 and 3.4 doesn't mean you need
to support 3.0 and 3.1.  2.x and 3.x are different languages. Just
as 2.4 is old and often not supported, 3.0 is old and often not
supported.

--Ned.

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

#90514

On Wed, 13 May 2015 04:18 am, Ned Batchelder wrote:

> On Tuesday, May 12, 2015 at 2:03:04 PM UTC-4, Rob Gaddi wrote:
[...]
>> B) If I can't manage that, what's the etiquette behind having later
>> versions of a module break compatibility with older versions of Python.
>> I've avoided using features I know are newer, like yield from and Enums,
>> but I won't swear it'll work on 3.0 if I can't test it that way.
> 
> No one supports 3.0 any more.  3.2 is kind of the oldest version
> that is still reasonable, and many people are only aiming for 3.3
> and 3.4.

No one *should* support 3.0. It is semi-officially "broken".

The first production-ready (i.e. "final") version of 3.0 was released on
December 3rd, 2008. It soon became obvious that it had serious problems,
and following a single point release (3.0.1) it reached official end of
life with the release of 3.1 on June 27th, 2009.

There's no outright prohibition on supporting 3.0, and if somebody wants to
use it they can (we can't stop you, it's FOSS), but unlike older versions
which have reached end of life in the fullness of time, 3.0 never had a
user-base actually relying on it in production. It would be a waste of time
to explicitly support it.

Anything written for 3.1 will probably work in 3.0, and if it doesn't, it's
probably a bug in 3.0. Either way, I wouldn't waste time fixing bugs that
only affected 3.0.


> Just because you are supporting 2.7 and 3.4 doesn't mean you need
> to support 3.0 and 3.1.  

I agree whole-heartily with that. 2.x and 3.x are a fork in the language,
and you can support older versions on one branch without necessarily doing
the same on the other branch.

# requires fixed-width font for best results

1.4->1.5->2.0->2.1->2.2->2.3->2.4->2.5->2.6->2.7
       \                           \
        \                           3.0->3.1->3.2->3.3->3.4
         1.6


(I am unsure whether what became 3.0 *literally* was forked from 2.4, I
suspect not, but 2.5 was intended as the first of the transition versions
for moving between 2.4 and what was then known as Python 3000, and 2.6 was
the first to explicitly include Python 3 features via the __future__
module.)


> 2.x and 3.x are different languages.  

I wish people wouldn't say that. They're different languages in the same
sense that American English and British English are different languages. I
prefer to emphasise the 98% similarities by calling them different dialects
than the 2% differences -- especially since it has turned out to be far
easier and more practical to write hybrid 2.x + 3.x code than anyone
imagined back in the Python 3000 days.



-- 
Steven

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

#90502

Rob Gaddi <rgaddi@technologyhighland.invalid> writes:

> A) Is there any easy way to test against an older version of Python?

The convention today is to use Tox for testing one code base using
multiple Python impleemntations, in a single test run.

    <URL:https://pypi.python.org/pypi/tox>

> Preferably without trying to install entire old environments and keep 
> them nicely isolated from my actual doing work?

That's what Python virtualenv functionality is for, and Tox makes good
use of it. This is well-trod ground.

> B) If I can't manage that, what's the etiquette behind having later
> versions of a module break compatibility with older versions of
> Python.

Consult your user community, tell them the issue (maintaining obsolete
Python versions is a lot of effort), and incrementally drop support with
subsequent versions. Give your user community a chance to upgrade their
stuff, but also don't take on an unreasonable burden. Involve them in
the process.

-- 
 \     “Don't be misled by the enormous flow of money into bad defacto |
  `\    standards for unsophisticated buyers using poor adaptations of |
_o__)                                     incomplete ideas.” —Alan Kay |
Ben Finney

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

#90505

On Wed, 13 May 2015 08:35:02 +1000, Ben Finney wrote:

> Rob Gaddi <rgaddi@technologyhighland.invalid> writes:
> 
>> B) If I can't manage that, what's the etiquette behind having later
>> versions of a module break compatibility with older versions of Python.
> 
> Consult your user community, tell them the issue (maintaining obsolete
> Python versions is a lot of effort), and incrementally drop support with
> subsequent versions. Give your user community a chance to upgrade their
> stuff, but also don't take on an unreasonable burden. Involve them in
> the process.

The only user community that I know about for this is three people, all 
of whom have desks within 50 feet of mine, and all of whom have sworn a 
solemn vow to do all of the actual development we care about under Python 
3.4 or higher.  I just noted that there were a bunch of downloads from 
John Q. Internet, and didn't know how poor of form breaking ancient 
compatibility was seen as.  The answer, at least here on c.l.p, seems to 
be "not particularly".


-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

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

#90506

Rob Gaddi <rgaddi@technologyhighland.invalid> writes:

> On Wed, 13 May 2015 08:35:02 +1000, Ben Finney wrote:
>
> > Rob Gaddi <rgaddi@technologyhighland.invalid> writes:
> > 
> >> B) If I can't manage that, what's the etiquette behind having later
> >> versions of a module break compatibility with older versions of
> >> Python.
> > 
> > Consult your user community, tell them the issue […] Involve them in
> > the process.
>
> The only user community that I know about for this is three people […]

Then, prior to questions of etiquette, you need to begin engaging with
your user community in the first place :-)

Seriously, if you have no good way of contacting your user community,
it's difficult to talk about the right way to treat with them. You might
first set up a forum (e.g. a mailing list) to discuss future releases
with them.

-- 
 \          “If you get invited to your first orgy, don't just show up |
  `\             nude. That's a common mistake. You have to let nudity |
_o__)                                          ‘happen.’” —Jack Handey |
Ben Finney

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web