Re: url2pkg only for Python 3

[Greg Troxel <gdt%lexort.com@localhost>]

Adam <adam%netbsd.org@localhost> writes:

> May I mark url2pkg as PYTHON_VERSIONS_INCOMPATIBLE=27? Or is anyone using it with Python 2.7?

I can't imagine anyone is, as it just needs to work for some version to
be useful.

> It stand in the way of removing py-test4. :)

I find this problematic.  Recursive removals without a discussed overall
plan are basically not ok, was more or less the conclusion from the
qt4-libs situation.

Right now, I think the situation is

  the upstreams of many py-foo release versions that no longer work with
  27 and we just mark them as such

  we have a bunch of versioned packages because of an upstream dropping
  support for 27 before things that depend on it dropped support.  When
  the 27-only version of such a package reaches "no depending packages
  in pkgsrc", we gc it

  We have not had a discussion about trying to proactively get rid of
  things that support 2.7.   We have not discussed the concept of
  marking things not-for-27 when they actually work fine.

  (Sort of related to this: I've heard the opinion that for a py-foo
  that isn't really obviously an end-user package, that it can be
  removed if nothing in pkgsrc uses it.  I think this is wrong; users
  can have their own scripts and use libraries (I in fact do this with
  py-paho-mqtt), and packages might well have a script entry point that
  is useful on its own (py-xmpp).)

  We have not had a discussion of whether we're ready to just decide to
  nuke all 2.7 things.  (Probably we wouldn't, as this would take out
  things like mongodb3, and surely others, and the real world needs 2.7
  still.)

and beyond that we don't have a plan.



I would be ok with saying we add to that as

  if a multi-python-version package is intended to do something useful,
  and there's no practice of using it as a dependency, and it supports
  multiple python versions, it's ok to mark it NOT FOR 27 and really any
  version that's old (say 2 older than default and below), on the theory
  that users have no reason to want a specific version, but rather to
  install the program and run it, and the default works fine.

and float that as a draft consensus view.


I remain not ok with "I want to remove X and therefore I want to remove
Y which depends on X".