Re: How to discontinue ports completely (py26 deprecation) ...

[Mojca Miklavec]

On 15 August 2016 at 03:52, Fred Wright wrote:
> On Sat, 13 Aug 2016, Christopher Jones wrote:
>>
>> I agree there is no way to migrate completely to 3.x, but I am still not
>> really convinced keeping both the 2.6 and 2.7 versions in MacPorts is
>> worth the effort. 2.6 needs to be dropped sometime...
>
> Given that the effort involved in keeping it is zero, and the effort
> involved in removing it is nonzero, I don't think the "effort" argument
> really flies.

One of the reasons for keeping support for 2.6 for me was the ability
(= hack) to keep both wxPython 2.8 and 3.0 installable side-by-side
(for example as py27-wxpython-3.0 and py26-wxpython-2.8).

See:
https://trac.macports.org/ticket/46351

But then again:
- this has been a known problem since the release of Lion (if not Snow
Leopard), more than five years ago
- there are currently exactly three ports affected:

  - py-dsv: a port which I plan to delete at some point (unless
someone has a strong objection)

  - grass: which is semi-broken anyway and I would be surprised if we
actually have any real users; not to misunderstand me, the software
seems great, but there's currently almost no manpower to fix our
*port* properly; and maybe wxPython 3.0 works better by now, who knows

  - py-robotframework-ride: maintained both upstream and in MacPorts;
but the upstream had the ticket open for almost 5 years and didn't
manage to do anything else beyond labelling the ticket as "high
priority"

I would like to get rid of py-wxpython-2.8 at some point. I don't want
to spend any effort in case it no longer compiles on the latest OS,
but if it requires zero effort to keep it there for the sake of one
port, so let it be.

I would no longer oppose the removal of py26-wxpython-2.8 though.

---

On a related note. It would be nice to establish a common policy about
the old software versions that are in principle still usable (and
potentially useful for MacPorters wishing to test their software
against those old software, but not of "general interest" / for the
sake of just being able to run software X that depends on
python/perl/whatever).

That includes perl5.8 - 5.20, python up to 2.6 and 3.3, ...

If I remember correctly, Homebrew split their collection of formulas
into several repositories. If MacPorts did something similar, we could
have a special repository for "abandonware", potentially in multiple
categories. That could include:

- ancient version of ruby, perl, python, apache, qt3, ...
- wxWidgets 2.8 (once we get rid of it as a dependency of other
software packages)
- ports that are no longer maintained upstream, have no maintainer in
macports, and might even be broken
- ports that could potentially work, but have no maintainer and need work
- ...

The benefits include:
- cleaner central collection of ports with less old crapware
- it would be easier to move a port to that special repository than to
remove the port altogether (I'm always reluctant to delete ports even
if I suspect that they are useless, but one never knows whether other
people use the software and are not subscribed to our mailing lists)
- it would be easier for users to find and install that software if they need it
- we could get a clear message to the users, saying that "maintainer
is needed" if they want the software to be improved
- no need for long discussions about whether apache1, perl5.20,
python26, ... should still be available or not: simply move them to
the other repository
- tickets could be opened, but would automatically be assigned lower
priority and some kind of message (we accept patches, but don't blame
anyone if nobody fixing this)
- buildbot could be configured to either build all the ports without
sending any emails about failures, or perhaps not build them at all

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Ned Deily]

On 2016-08-14 21:52, Fred Wright wrote:
> 
> On Sat, 13 Aug 2016, Christopher Jones wrote:
>>> On 12 Aug 2016, at 11:30 pm, Fred Wright 
>>>  wrote:
>>> On Fri, 12 Aug 2016, Chris Jones wrote:
>> I agree there is no way to migrate completely to 3.x, but I am still not
>> really convinced keeping both the 2.6 and 2.7 versions in MacPorts is
>> worth the effort. 2.6 needs to be dropped sometime... 
> Given that the effort involved in keeping it is zero, and the effort
> involved in removing it is nonzero, I don't think the "effort" argument
> really flies.

Unfortunately, it's not true that the effort is zero.  The most obvious
example is supporting new OS X / macOS releases.  Often there are subtle
change in a release that have unexpected consequences and break old
end-of-life releases, like 2.6 for which upstream support ended years
ago.  Another example is changing network and security standards which
can cause old versions running on old OS X releases to break.  Python
2.6 (and earlier, as well as older, non-current versions of Python 3.x)
has examples of both of these problems. The last upstream release of
2.6.x will not build or test correctly on current OS X systems.  That
means the downstream distributors, like MacPorts, have to investigate,
backport and/or develop new fixes, test them, then test and update them
with newer OS X releases.  And that's just for the Python interpreter
and standard library.  Similar issues arise with third-party Python
packages that may or may not be supported on older versions by their
upstream developers.  Although I'm not a MacPorts developer, from an
upstream point of view I'm fully supportive of dropping 2.6 ports at
this point.  I'd rather see the MacPorts project volunteers spend their
precious time on things that will help more people.  2.7.x is a special
case and upstream has committed to fully support it until 2020 and to
keep 2.7.x running on new releases, we still have to do work upstream.
That doesn't mean everybody should have to for retired releases.  And,
regardless of other options (like migrating to Python 3.x), I can't
imagine that it would be very difficult to migrate nearly anything that
is still running on Python 2.6.x to 2.7.x.  IMHO, it's really not doing
anyone any service to keep 2.6.x and other old releases alive at this stage.

--
 Ned Deily
 n...@acm.org -- []
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Fred Wright]

On Sat, 13 Aug 2016, Christopher Jones wrote:
> > On 12 Aug 2016, at 11:30 pm, Fred Wright  wrote:
> > On Fri, 12 Aug 2016, Chris Jones wrote:
> >> On 11/08/16 20:40, Fred Wright wrote:
> > [...]
> >>> Well, leaving something alone that's working just fine is hardly much of a
> >>> maintenance burden.
> >>
> >> On the other hand, whats the rationale for keeping 2.6, given 2.7 is the
> >> official upstream production version of the 2.x series. What use case
> >> requires 2.6 and cannot move to 2.7 ?
> >
> > Testing code against 2.6 (among others), because it's intended to run on a
> > wide range of platforms, and one wants to make as few assumptions as
> > possible about what Python version(s) the end user might have installed.
> > Some distros lag *way* behind in versions of various things, including
> > Python.
> >
> > If the python.org folks had their way, all 2.x versions would be
> > eradicated, but there were too many pitchforks at the gates to let that
> > happen. :-)
>
> I agree there is no way to migrate completely to 3.x, but I am still not
> really convinced keeping both the 2.6 and 2.7 versions in MacPorts is
> worth the effort. 2.6 needs to be dropped sometime...

Given that the effort involved in keeping it is zero, and the effort
involved in removing it is nonzero, I don't think the "effort" argument
really flies.

I mainly mentioned 3.x as an illustration of how different people have
different opinions as to when older versions of something should be
abandoned, often for good reasons.

Apple declared PowerMacs obsolete a decade ago, but some of us still have
some that work, and which still get used for testing PowerPC code. :-)

As I said, the main value of 2.6 is for testing.  If I publish code that
claims to be compatible with 2.6, then that means I've actually tested it
with 2.6.  And *I* don't want to tell people running 2.6 that they have to
upgrade unless there's a good reason for it.  Even upgrading to a
nominally compatible new version may involve a lot of testing to be sure
it really doesn't break anything.

Fred Wright
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Christopher Jones]

> On 12 Aug 2016, at 11:30 pm, Fred Wright  wrote:
> 
> 
> On Fri, 12 Aug 2016, Chris Jones wrote:
>> On 11/08/16 20:40, Fred Wright wrote:
> [...]
>>> Well, leaving something alone that's working just fine is hardly much of a
>>> maintenance burden.
>> 
>> On the other hand, whats the rationale for keeping 2.6, given 2.7 is the
>> official upstream production version of the 2.x series. What use case
>> requires 2.6 and cannot move to 2.7 ?
> 
> Testing code against 2.6 (among others), because it's intended to run on a
> wide range of platforms, and one wants to make as few assumptions as
> possible about what Python version(s) the end user might have installed.
> Some distros lag *way* behind in versions of various things, including
> Python.
> 
> If the python.org folks had their way, all 2.x versions would be
> eradicated, but there were too many pitchforks at the gates to let that
> happen. :-)

I agree there is no way to migrate completely to 3.x, but I am still not really 
convinced keeping both the 2.6 and 2.7 versions in MacPorts is worth the 
effort. 2.6 needs to be dropped sometime...

Chris

> 
> Fred Wright
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev



smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Fred Wright]

On Fri, 12 Aug 2016, Chris Jones wrote:
> On 11/08/16 20:40, Fred Wright wrote:
[...]
> > Well, leaving something alone that's working just fine is hardly much of a
> > maintenance burden.
>
> On the other hand, whats the rationale for keeping 2.6, given 2.7 is the
> official upstream production version of the 2.x series. What use case
> requires 2.6 and cannot move to 2.7 ?

Testing code against 2.6 (among others), because it's intended to run on a
wide range of platforms, and one wants to make as few assumptions as
possible about what Python version(s) the end user might have installed.
Some distros lag *way* behind in versions of various things, including
Python.

If the python.org folks had their way, all 2.x versions would be
eradicated, but there were too many pitchforks at the gates to let that
happen. :-)

Fred Wright
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Chris Jones]

On 11/08/16 20:40, Fred Wright wrote:



On Wed, 10 Aug 2016, Lawrence Velázquez wrote:


On Aug 10, 2016, at 5:21 PM, Fred Wright  wrote:


I don't consider Python 2.6 to be "cruft".  Developers need many
versions of Python installed for testing, and that includes any
packages that are also needed.  It's annoying to have to create local
versions of portfiles solely to add versions that are missing for no
substantive reason.


The substantive reason is that every additional version of CPython we
support is a maintenance burden, especially one that saw its last
feature release 6 years ago and its last bugfix release nearly 3 years
ago.


Well, leaving something alone that's working just fine is hardly much of a
maintenance burden.


On the other hand, whats the rationale for keeping 2.6, given 2.7 is the 
official upstream production version of the 2.x series. What use case 
requires 2.6 and cannot move to 2.7 ?


Chris



BTW, there's some erroneous information that making code compatible with
both Python 2 and Python 3 requires 2.7.  I have yet to encounter any
issues with "polyglot" code per se on Python 2.6.  Anything earlier is
definitely problematic, however.

Fred Wright
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Fred Wright]

On Thu, 11 Aug 2016, Lawrence Velázquez wrote:

> > On Aug 11, 2016, at 3:40 PM, Fred Wright  wrote:
> >
> > Well, leaving something alone that's working just fine is hardly much
> > of a maintenance burden.
>
> As Josh noted, this approach is fine for CPython itself, but less so
> for modules. As they work to keep their modules up to date, maintainers
> can hardly be expected to support subports for Python versions that
> don't build on recent OSes (although they are certainly welcome to if
> they wish).

But often the subports work fine as well.  For example, here I have local
versions of seven py-xxx ports just to expand the version lists.  In five
of the cases, expanding the version lists "just worked".  The other two
ports each had a set of version-specific files (for no obvious reason,
given the content) which just needed to be trivially and obviously
expanded for the added versions.

Fred Wright
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Lawrence Velázquez]

> On Aug 11, 2016, at 3:40 PM, Fred Wright  wrote:
> 
> Well, leaving something alone that's working just fine is hardly much
> of a maintenance burden.

As Josh noted, this approach is fine for CPython itself, but less so
for modules. As they work to keep their modules up to date, maintainers
can hardly be expected to support subports for Python versions that
don't build on recent OSes (although they are certainly welcome to if
they wish).

> BTW, there's some erroneous information that making code compatible
> with both Python 2 and Python 3 requires 2.7.  I have yet to encounter
> any issues with "polyglot" code per se on Python 2.6.  Anything
> earlier is definitely problematic, however.

For sure. Maintaining source compatibility between 2.6 and 3.x is
annoying but far from impossible.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Fred Wright]

On Wed, 10 Aug 2016, Lawrence Velázquez wrote:

> On Aug 10, 2016, at 5:21 PM, Fred Wright  wrote:
>
> > I don't consider Python 2.6 to be "cruft".  Developers need many
> > versions of Python installed for testing, and that includes any
> > packages that are also needed.  It's annoying to have to create local
> > versions of portfiles solely to add versions that are missing for no
> > substantive reason.
>
> The substantive reason is that every additional version of CPython we
> support is a maintenance burden, especially one that saw its last
> feature release 6 years ago and its last bugfix release nearly 3 years
> ago.

Well, leaving something alone that's working just fine is hardly much of a
maintenance burden.

BTW, there's some erroneous information that making code compatible with
both Python 2 and Python 3 requires 2.7.  I have yet to encounter any
issues with "polyglot" code per se on Python 2.6.  Anything earlier is
definitely problematic, however.

Fred Wright
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Joshua Root]

On 2016-8-11 08:01 , Lawrence Velázquez wrote:

On Aug 10, 2016, at 5:21 PM, Fred Wright  wrote:


I don't consider Python 2.6 to be "cruft".  Developers need many
versions of Python installed for testing, and that includes any
packages that are also needed.  It's annoying to have to create local
versions of portfiles solely to add versions that are missing for no
substantive reason.


The substantive reason is that every additional version of CPython we
support is a maintenance burden, especially one that saw its last
feature release 6 years ago and its last bugfix release nearly 3 years
ago.


For the pythonXY ports themselves (and surely we should be starting with 
python24 if we're removing things?), I don't think it's much of a burden 
to slap a big warning on them about vulnerabilities and then never touch 
them again. For py26 module subports, it is of course up to the 
maintainer. I'm pretty sure most of the nomaintainer module ports have 
had 26 removed already.


That said, you're probably better off using pip in virtualenv for your 
multi python version testing.


- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Joshua Root]

On 2016-8-11 10:50 , Clemens Lang wrote:

On Wed, Aug 10, 2016 at 04:47:25PM -0500, Ryan Schmidt wrote:

On Aug 10, 2016, at 13:18, Peter Danecek  wrote:


However, how would we procede in this case, when we have no explicit
replacement to indicate?


I believe the obsolete 1.0 portgroup can accommodate this: include the
portgroup but don't set replaced_by.

However, do first consider whether this needs to be done, or whether
the port can instead be left as is.


What's the benefit of replacing a port we might no longer want to keep
with an explicit error message on upgrade? Instead, we could just
outright delete the port, which will leave it installed on the systems
of those users that had it installed (i.e. not break their system), but
also no longer allow fresh installations of it.


That is how it's been done historically. Failing with an error when the 
user is just trying to 'port upgrade outdated' is pretty poor UX.


- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Clemens Lang]

On Wed, Aug 10, 2016 at 04:47:25PM -0500, Ryan Schmidt wrote:
> On Aug 10, 2016, at 13:18, Peter Danecek  wrote:
> > 
> > However, how would we procede in this case, when we have no explicit
> > replacement to indicate?
> 
> I believe the obsolete 1.0 portgroup can accommodate this: include the
> portgroup but don't set replaced_by. 
> 
> However, do first consider whether this needs to be done, or whether
> the port can instead be left as is. 

What's the benefit of replacing a port we might no longer want to keep
with an explicit error message on upgrade? Instead, we could just
outright delete the port, which will leave it installed on the systems
of those users that had it installed (i.e. not break their system), but
also no longer allow fresh installations of it.

-- 
Clemens
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Lawrence Velázquez]

On Aug 10, 2016, at 2:18 PM, Peter Danecek  wrote:

> In the process of deprecating `py26` subports, I am just looking at
> some very old python packages which were never moved to Python 2.7. It
> seems that in most cases there is a "good reason" why this did not
> occur. They are just not used anymore.
> 
> Some of these packages are deprecated explicitly upstream in favour of
> substitutes. Sometimes the homepage or the sources can not be found
> found, or are extremely outdated. So rather than just keeping them
> alive in Macports (by moving them to Python 2.7 even if they build),
> I would propose to remove them completely.

What ports are these?

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Lawrence Velázquez]

On Aug 10, 2016, at 5:21 PM, Fred Wright  wrote:

> I don't consider Python 2.6 to be "cruft".  Developers need many
> versions of Python installed for testing, and that includes any
> packages that are also needed.  It's annoying to have to create local
> versions of portfiles solely to add versions that are missing for no
> substantive reason.

The substantive reason is that every additional version of CPython we
support is a maintenance burden, especially one that saw its last
feature release 6 years ago and its last bugfix release nearly 3 years
ago.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Ryan Schmidt]

On Aug 10, 2016, at 13:18, Peter Danecek  wrote:
> 
> However, how would we procede in this case, when we have no explicit 
> replacement to indicate?

I believe the obsolete 1.0 portgroup can accommodate this: include the 
portgroup but don't set replaced_by. 

However, do first consider whether this needs to be done, or whether the port 
can instead be left as is. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Fred Wright]

On Wed, 10 Aug 2016, Sterling Smith wrote:

> I am all in favor of removing cruft.  However, would it be worthwhile to
> ping the user email list about the ports that will be deprecated (give a
> specific list), to see if anyone will complain, or is it better to just
> remove them, and then when someone complains tell them how to go back to
> an old version of a Port?

I don't consider Python 2.6 to be "cruft".  Developers need many versions
of Python installed for testing, and that includes any packages that are
also needed.  It's annoying to have to create local versions of portfiles
solely to add versions that are missing for no substantive reason.

Python 2.6 here:

MacPro:~ fw$ port installed|egrep 'py(|thon)26'
  py26-cairo @1.10.0_3 (active)
  py26-pip @8.1.2_0 (active)
  py26-readline @6.2.4.1_1 (active)
  py26-setuptools @25.1.0_0 (active)
  python26 @2.6.9_4 (active)

Fred Wright
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to discontinue ports completely (py26 deprecation) ...

[Sterling Smith]

Petr,

I am all in favor of removing cruft.  However, would it be worthwhile to ping 
the user email list about the ports that will be deprecated (give a specific 
list), to see if anyone will complain, or is it better to just remove them, and 
then when someone complains tell them how to go back to an old version of a 
Port?

-Sterling


On Aug 10, 2016, at 11:18AM, Peter Danecek  wrote:

> 
> Hi all,
> 
> In the process of deprecating `py26` subports, I am just looking at some very 
> old python packages which were never moved to Python 2.7. It seems that in 
> most cases there is a "good reason" why this did not occur. They are just not 
> used anymore.
> 
> Some of these packages are deprecated explicitly upstream in favour of 
> substitutes. Sometimes the homepage or the sources can not be found found, or 
> are extremely outdated. So rather than just keeping them alive in Macports 
> (by moving them to Python 2.7 even if they build), I would propose to remove 
> them completely. 
> 
> However, how would we procede in this case, when we have no explicit 
> replacement to indicate?
> Just replace it by a stub?
> Just removing it the fast way?
> 
> Thanks!
> ~petr
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

How to discontinue ports completely (py26 deprecation) ...

[Peter Danecek]

Hi all,

In the process of deprecating `py26` subports, I am just looking at some very 
old python packages which were never moved to Python 2.7. It seems that in most 
cases there is a "good reason" why this did not occur. They are just not used 
anymore.

Some of these packages are deprecated explicitly upstream in favour of 
substitutes. Sometimes the homepage or the sources can not be found found, or 
are extremely outdated. So rather than just keeping them alive in Macports (by 
moving them to Python 2.7 even if they build), I would propose to remove them 
completely. 

However, how would we procede in this case, when we have no explicit 
replacement to indicate?
Just replace it by a stub?
Just removing it the fast way?

Thanks!
~petr

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev