On Sat, Sep 3, 2016 at 2:32 PM, Nick Coghlan wrote:
>
> * Tier 0: "the default Python" is determined at the distribution
> level. For the majority of current distributions, that means Python 2,
> but on a select few it means Python 3.
>
> * Tier 1: "the default Python" is configurable on a per-sy
On Thu, Sep 1, 2016 at 10:22 AM, Petr Viktorin wrote:
>
> Whatever we do, I'd like it to be coordinated across multiple
> distrubutions, and blesed by a PEP like [PEP 394]. We don't want a solution
> specific to Fedora.
>
Completely agree. Based on the suggestions offered in PEP 394, we would
ne
On Thu, Sep 1, 2016 at 8:40 AM, Neal Gompa wrote:
> Sure, but those scripts may not actually work because modules that are
> supposed to be there, aren't. For example, if you depend on a
> non-standard lib module, then that means it needs to be installed for
> each python version supported. How d
On Thu, Sep 1, 2016 at 8:14 AM, Neal Gompa wrote:
> Alternatives doesn't work in this case because Python 2.x and Python
> 3.x versions don't share resources, even with minor versions of the
> same series. Enabling alternatives for it is a recipe for disaster.
>
Could you elaborate? The use case
On Thu, Sep 1, 2016 at 7:44 AM, Nick Coghlan wrote:
>
> The ideal point we'd like to get to is one where all distro provided
> scripts actually have the appropriate major version in their shebang
> lines, and the unqualifed "python" is something along the lines of a
> user-configurable launcher,
On Wed, Aug 24, 2016 at 8:44 PM, Jason L Tibbitts III
wrote:
>
> To be completely fair, I don't actually know EPEL policy here. The rule
> is that you can't conflict with RHEL packages, but SRPMs aren't really
> installed the same way as other packages and whether or not they would
> install to
>
> Which is an annoying bit of process, but it would be quite possible to
> exempt those packages from needing package reviews. It needn't take
> that long.
>
>
Not needing reviews would help, but I wonder how hard it would be to make
them children of python-PACKAGE. The main issue is the SRPM ne
Definitely, but it runs into the same problem as 3.4 on EL7, the fact that
there are few packages available and adding them when the package already
exists in RHEL requires creating a separate parent package in Fedora pkgdb.
On Wed, Aug 24, 2016 at 5:38 PM, Orion Poplawski
wrote:
> I have no ide
Is an unversioned python(name) also being created automagically? I manually
create these for the command line tools which support multiple Python
versions, where the python2-name and python3-name package both provide
python(name) and then the name package requires python(name) with a
recommends for
I wasn't able to find much recent discussion on this, but I'm a bit
frustrated that there is so much manual work being done creating symlinks
when a system already exists for that.
It seem many projects which support both python2 and python3 are depending
on a hardcoded shebang, install order, or
x27;s
working with python2, then I would revert to use python2 for Fedora 23 and
work with upstream to get it cleaned up for Fedora 24.
On Sun, Apr 24, 2016 at 1:28 PM, Avram Lubkin wrote:
> Looks like the version argument was deprecated and later removed. The
> version of argparse 2.7 i
Looks like the version argument was deprecated and later removed. The
version of argparse 2.7 is using includes it with a deprecation warning and
the version for 3.4 has it removed.
On Sun, Apr 24, 2016 at 1:21 PM, Avram Lubkin wrote:
> Based on the error and looking at the source, you sho
Based on the error and looking at the source, you should just need to fix
the line in /usr/lib/python3.4/site-packages/krop/krop.py:
parser = ArgumentParser(description=__doc__, version=__version__,
with
parser = ArgumentParser(description=__doc__,
ArgumentParser does not accept a versi
So, a package I help maintain, python-dns is now provided by Red Hat. So I
thought, "OK, I'll still build the python34 package to help in that
effort". But the problem with that is, per the EPEL 7 in Python 3 Plan
Draft (1), if Red Hat provides the package, the SRPM can't use the same
name. I can s
So what should package maintainers do? I modified a package to use
python3_pkgversion and it builds fine if with_python3 is set, but it
doesn't seem to be set in the EPEL 7 build environment. I noticed a couple
packages enable it by default. Is that what we should be doing? Or should
we just build
Just thought I'd let this list know python-scandir is now in the stable
repos. The code itself has been accepted as an enhancement to the os module
in Python 3.5, but the original independent module is great for older
versions. I tend to use as an optional speedup when I am heavily using
os.walk()
16 matches
Mail list logo
