Re: Default BuildOption(install) for the RPM pyproject declarative buildsystem

Hello, I recommend starting out with the explicit option. Requiring BuildOption(install) sounds good, and can be changed to a better default after people get some experience with the system. -- ___ python-devel mailing list -- python-devel@lists.fedora

Re: Default BuildOption(install) for the RPM pyproject declarative buildsystem

Hello, I recommend starting out with the explicit option. Requiring BuildOption(install) sounds good, and can be changed to a better default after people get some experience with the system. -- ___ python-devel mailing list -- python-devel@lists.fedora

Re: PyPI name blocking request for vkbasalt-cli

On 16. 05. 23 16:32, Sandro wrote: On 16-05-2023 16:04, Petr Viktorin wrote: Did I misunderstand/misinterpret the guidelines? The review is currently stalled due to the PyPI parity issue. Should I approach PyPI folks myself and ask them to block vkbasalt-cli for me? Any kind of guidance is

Re: PyPI name blocking request for vkbasalt-cli

On 16. 05. 23 13:15, Sandro wrote: On 05-05-2023 15:10, Sandro wrote: On 27-04-2023 14:26, Sandro wrote: Well, I submitted the package for review [2] and have been told that vkbasalt not being published on PyPI is an issue wrt naming parity. So, I filed a bug requesting publication on PyPI [3]

Re: Package naming for vkbasalt-cli

Hi! On 21. 04. 23 12:46, Sandro wrote: Hi, I need to package vkbasalt-cli [1] as a dependency for Bottles. Bottles will use the Python library, but vkbasalt-cli also provides a command for independent/direct usage. My plan is to name the Fedora package 'vkbasalt-cli' in line with upstream

Re: Building Python 3.12 with no-omit-frame-pointer

On 22. 11. 22 18:30, Miro Hrončok wrote: On 21. 11. 22 11:01, Petr Viktorin wrote: And since the Python slowdown comes from a single weird function, I think that Fedora should ignore the Python benchmarks when evaluating the distro default -- and if Fedora switches to no-omit-frame-pointer

Re: Building Python 3.12 with no-omit-frame-pointer

On 09. 11. 22 12:37, Petr Viktorin wrote: tl;dr: Python 3.12 should be built with no-omit-frame-pointer if upstream recommends it. Hello, You might be aware of a Fedora change proposal [0] (discussed on fedora-devel [1] and FESCo [2]) are discussing turning on C compiler flags that help

Re: Building Python 3.12 with no-omit-frame-pointer

On 15. 11. 22 20:17, Kevin Kofler wrote: tl;dr: Python 3.12 should be built with no-omit-frame-pointer if upstream recommends it. Absolutely not, because… Apparently there are some benchmarks that make Python look extra slow when the flags are turned on … considering those benchmarks, Pytho

Building Python 3.12 with no-omit-frame-pointer

tl;dr: Python 3.12 should be built with no-omit-frame-pointer if upstream recommends it. Hello, You might be aware of a Fedora change proposal [0] (discussed on fedora-devel [1] and FESCo [2]) are discussing turning on C compiler flags that help with performance *measurement*, but might hurt

Re: What if we excluded 32bit ARM from Python 3.12

Makes sense. It's a new package. I see nothing wrong with excluding it, to see what breaks & who complains. On 13. 10. 22 11:07, Miro Hrončok wrote: Hello Pythonistas, we are probably going to package python3.12 soon for all Fedora releases. Unfortunately, building Python for 32bit ARM has b

Re: Cython build failing on longintrepr.h not found

The guidelines have more info: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_using_cython On 27. 09. 22 8:17, Lumír Balhar wrote: Hi Sandro. Make sure that the build does not use the pyx file from upstream. It seems to me that the file generated by Cython is in the sourc

Re: Orphaned python packages

On 31. 08. 22 13:41, Ali Erdinc Koroglu wrote: - pytest-capturelog not even exits in pypi [2] so can we retire it and use pytest-catchlog instead ? Yes. Except pytest-catchlog is retired too, because pytest itself provides the functionality now: https://docs.pytest.org/en/latest/how-to/logg

Re: Replacing pytest -n auto with pytest -n %{_smp_build_ncpus}

On 07. 07. 22 14:44, Miro Hrončok wrote: On 07. 07. 22 14:00, Petr Viktorin wrote: On 07. 07. 22 11:38, Miro Hrončok wrote: Hello Pythonistats, packagers, A handful of Fedora Python packages uses pytest-xdist to run tests in parallel like this:    %pytest -n auto -n auto means pytest

Re: Replacing pytest -n auto with pytest -n %{_smp_build_ncpus}

On 07. 07. 22 11:38, Miro Hrončok wrote: Hello Pythonistats, packagers, A handful of Fedora Python packages uses pytest-xdist to run tests in parallel like this:   %pytest -n auto -n auto means pytest will spawn a number of workers processes equal to the number of available CPUs. In the

Re: Should python3dist(...) provides generator fail when the version is = 0?

On 29. 01. 22 22:11, Miro Hrončok wrote: Hello Pythonistas, today, I've looked up packages in rawhide providing python3dist(...) = 0 and I opened bugzillas for them: https://bugzilla.redhat.com/showdependencytree.cgi?id=python3dist0 While version 0 (or equal versions like 0.0 or 0.0.0) is

Re: Adding python3.10dist(pp) to python-ppft

On 07. 12. 21 22:42, Ankur Sinha wrote: Hi folks, I was looking to unretire the unmaintained python-pp because some neuro packages still use it but then was reminded by @music that we already provide python-ppft which is a maintained fork and drop-in replacement for pp. https://github.com/uqfou

Re: Python RPM dependency generators and LegacyVersion, time to error?

On 04. 11. 21 12:49, Miro Hrončok wrote: Hello Pythonistas. After some recent improvements in the Python RPM dependency generators, a regression was discovered [0]. Turns out the error happened when the upstream metadata contained a requirement with a PEP 440 [1] incompatible version. A fi

Re: Using reverse week deps for Python interpreters and tox (Supplements instead of Recommends)?

On Wed, Aug 11, 2021 at 3:00 PM Miro Hrončok wrote: > > Hello Pythonistas. > > Currently, the tox package has: > ># Recommend "all the Pythons" >Recommends: python2.7 >Recommends: python3.6 >Recommends: python3.7 >Recommends: python3.8 >Recommends: pytho

Re: An unsuccessful case study: Using pyproject-rpm-macros with PyQt-builder and sip 5

Hi, This looks like the pip issue for passing options to backends (like sip-build, presumably): https://github.com/pypa/pip/issues/5771 On 23. 06. 21 13:17, Miro Hrončok wrote: Hello, since Scott is working on update to sip 5 (thank you!) I've figured this is a good time check if we can use

Re: Draft of New Python Packaging Guidelines

le module name. That's bad, and the guidelines recommend not having this problem, but usually you can't really solve this in Fedora. -Toshio On Fri, Jun 11, 2021, 6:24 AM Petr Viktorin <mailto:pvikt...@redhat.com>> wrote: I've proposed the new guidelines as

Re: Draft of New Python Packaging Guidelines

I've proposed the new guidelines as a Fedora change: https://fedoraproject.org/wiki/Changes/PythonPackagingGuidelines202x A discussion thread should pop up on de...@lists.fedoraproject.org soon. ___ python-devel mailing list -- python-devel@lists.fedor

Re: Draft of New Python Packaging Guidelines - 0.3

y run into the same problem. Ultimately, syncing Fedora with the wider Python ecosystem is the main idea behind the draft. I'd be glad to hear how it can be done better, but to me, the new guidelines wouldn't make sense without this part. On 4/30/20 3:41 PM, Petr Viktorin wrote: Hello

Re: Draft of New Python Packaging Guidelines - 0.2

On 2020-08-12 18:19, Neal Gompa wrote: On Wed, Aug 12, 2020 at 12:02 PM Petr Viktorin wrote: On 2020-08-12 17:22, Neal Gompa wrote: On Wed, Aug 12, 2020 at 11:19 AM Petr Viktorin wrote: On 2020-08-12 16:53, Neal Gompa wrote: On Wed, Aug 12, 2020 at 10:23 AM Petr Viktorin wrote: @Conan

Re: Draft of New Python Packaging Guidelines - 0.2

On 2020-08-12 17:22, Neal Gompa wrote: On Wed, Aug 12, 2020 at 11:19 AM Petr Viktorin wrote: On 2020-08-12 16:53, Neal Gompa wrote: On Wed, Aug 12, 2020 at 10:23 AM Petr Viktorin wrote: I'll move some discussion here, where it doesn't become part of the document: On 2020-0

Re: Draft of New Python Packaging Guidelines - 0.2

On 2020-08-12 16:53, Neal Gompa wrote: On Wed, Aug 12, 2020 at 10:23 AM Petr Viktorin wrote: I'll move some discussion here, where it doesn't become part of the document: On 2020-08-11 14:19, Petr Viktorin wrote: These Guidelines represent a major rewrite and paradigm shift, a

Re: Draft of New Python Packaging Guidelines - 0.2

I'll move some discussion here, where it doesn't become part of the document: On 2020-08-11 14:19, Petr Viktorin wrote: These Guidelines represent a major rewrite and paradigm shift, and not all packages are updated to reflect this. Older guidelines are still being kept up to

Draft of New Python Packaging Guidelines - 0.2

team for the work on this and on the related macro improvements — some of which made it to the current, "non-pyproject" macros as well; see https://pagure.io/packaging-committee/pull-request/1011 On 2020-04-30 15:41, Petr Viktorin wrote: ... Generally, for rules marked **SHOULD**

Re: Suppress "running pip install with root privileges" warning in RPM macros?

On 2020-07-07 19:54, Miro Hrončok wrote: 1) Add a custom --no-warn-root-privileges option 2) Hide the warning when $RPM_BUILD_ROOT is set. 3) Introduce an environment variable (e.g. PIP_NOWARN_ROOT) 4) Introduce our warning upstream, but make it opt-in only. 5) Hide the warning when --root is set

Re: Draft of New Python Packaging Guidelines

On 2020-06-11 13:22, Tomas Orsava wrote: On 6/9/20 12:15 PM, Petr Viktorin wrote: On 2020-06-08 12:15, Tomas Orsava wrote: On 6/8/20 11:58 AM, Petr Viktorin wrote: [...] https://hackmd.io/XzJe-sHUQvWK7cSrEH_aKg Looks good, thank you. All in all, really nice document. Let me know if you

Re: Draft of New Python Packaging Guidelines

On 2020-06-08 12:15, Tomas Orsava wrote: On 6/8/20 11:58 AM, Petr Viktorin wrote: On 2020-06-05 16:12, Tomas Orsava wrote: On 6/5/20 2:26 PM, Petr Viktorin wrote: On 2020-06-05 11:51, Tomas Orsava wrote: On 6/5/20 11:26 AM, Petr Viktorin wrote: On 2020-06-03 21:49, Tomas Orsava wrote

Re: Draft of New Python Packaging Guidelines

On 2020-06-05 16:12, Tomas Orsava wrote: On 6/5/20 2:26 PM, Petr Viktorin wrote: On 2020-06-05 11:51, Tomas Orsava wrote: On 6/5/20 11:26 AM, Petr Viktorin wrote: On 2020-06-03 21:49, Tomas Orsava wrote: Hi, I have left a few notes about the text itself as comments in the document

Re: Draft of New Python Packaging Guidelines

On 2020-06-05 15:37, Tomas Orsava wrote: On 6/5/20 2:22 PM, Petr Viktorin wrote: On 2020-06-05 13:58, Tomas Orsava wrote: On 6/5/20 1:43 PM, Miro Hrončok wrote: On 05. 06. 20 11:51, Tomas Orsava wrote: [...] I see what you mean. On the other hand, that's a pretty horrible

Re: Draft of New Python Packaging Guidelines

On 2020-06-05 11:51, Tomas Orsava wrote: On 6/5/20 11:26 AM, Petr Viktorin wrote: On 2020-06-03 21:49, Tomas Orsava wrote: Hi, I have left a few notes about the text itself as comments in the document. Comments about the subject matter are inlined below: On 4/30/20 3:41 PM, Petr Viktorin

Re: Draft of New Python Packaging Guidelines

On 2020-06-05 13:58, Tomas Orsava wrote: On 6/5/20 1:43 PM, Miro Hrončok wrote: On 05. 06. 20 11:51, Tomas Orsava wrote: [...] I see what you mean. On the other hand, that's a pretty horrible error message format (posting in it's entirety for others to consider). Is there no better way

Re: Draft of New Python Packaging Guidelines

On 2020-06-03 21:49, Tomas Orsava wrote: Hi, I have left a few notes about the text itself as comments in the document. Comments about the subject matter are inlined below: On 4/30/20 3:41 PM, Petr Viktorin wrote: ### Dist-info metadata Each Python package **MUST** include *Package

Re: Freecad and Python 3.9 help needed

On 2020-06-01 19:20, Richard Shaw wrote: I'm trying to rebuild FreeCAD but I've run into the following and I don't know how to fix it. The "Py::Int" is not Python API; it probably comes from C++. Do you know where it's defined? I haven't been able to find the definition, and searching for "Py

Re: Draft of New Python Packaging Guidelines

On 2020-05-06 11:24, Lumir Balhar wrote: I've took a look and the new guidelines look good to me. The only thing I am afraid of is that there is a lot of magic behind new macros. Previously, macros were a way how to use standard Python commands like "python3 setup.py build" without memorizing

Re: Macronize %py3_shebang_fix

On 2020-05-06 13:44, Miro Hrončok wrote: In this change: https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error We have advised the following:   pathfix.py -pni "%{__python3} %{py3_shbang_opts}" To fix the shebangs.  -p preserves timestamps  -n prevents creating ~b

Re: Draft of New Python Packaging Guidelines

On 2020-04-30 15:41, Petr Viktorin wrote: Hello! Below is a draft of new Packaging Guidelines! It's full of unfinished areas (marked with XXX), but it's ready for scrutiny. A possibly updated version is on https://hackmd.io/XzJe-sHUQvWK7cSrEH_aKg?view [...] The draft lives on hackmd

Re: Draft of New Python Packaging Guidelines

On 2020-05-01 23:41, Michel Alexandre Salim wrote: Hi, On 4/30/20 6:41 AM, Petr Viktorin wrote: The draft lives on hackmd.io, which we found easy to collaborate with. If you have an account there, we can add you. If you'd like to collaborate some other way, let us know. Please ad

Draft of New Python Packaging Guidelines

Hello! Below is a draft of new Packaging Guidelines! It's full of unfinished areas (marked with XXX), but it's ready for scrutiny. A possibly updated version is on https://hackmd.io/XzJe-sHUQvWK7cSrEH_aKg?view Generally, for rules marked **SHOULD** we know of cases where they should be broken

Re: Redesigning the %python_provide macro from scratch

I finally got around to this mail... On 2020-04-19 16:55, Miro Hrončok wrote: Hello Python packagers. After touching the %python_provide topic in: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/SSJLPWSGFGPYRSHXQZDR7JNQXSDGGX3Z/ I have realized sev

Re: Why is python(abi) generated? (Re: Rawhide python-rpm-generators news)

On 2020-04-07 12:40, Miro Hrončok wrote: On 07. 04. 20 11:06, Petr Viktorin wrote: On 2020-04-03 20:44, Miro Hrončok wrote: Hello Python packagers. I have just updated python-rpm-generators to python-rpm-generators-11-1.fc33 in Rawhide. It uses some fresh stuff from RPM 4.16 and will not be

Why is python(abi) generated? (Re: Rawhide python-rpm-generators news)

On 2020-04-03 20:44, Miro Hrončok wrote: Hello Python packagers. I have just updated python-rpm-generators to python-rpm-generators-11-1.fc33 in Rawhide. It uses some fresh stuff from RPM 4.16 and will not be backported to older releases. The python(abi) requirement is now added from a RPM

Re: Self-introduction

On 2019-12-31 13:55, Fabian Affolter wrote: Hi all, I don't want to repeat myself, please take a look at my wiki page [1]. Why I want to join? I have one too many Python package and I started to add the python-sig as admin. But it goes both ways, if the SIG has access to my packages I want to b

Re: Python bindings for protobuf on RHEL/CentOS/EPEL 8

on. Kind regards Denis 14 Nov. 2019 15:27, Petr Viktorin mailto:pvikt...@redhat.com>> wrote: On 2019-11-11 11:45, Denis Arnaud wrote: > Hi, > > the Python (3) bindings are missing on RHEL/CentOS/EPEL 8 for the

Re: Python bindings for protobuf on RHEL/CentOS/EPEL 8

On 2019-11-11 11:45, Denis Arnaud wrote: Hi, the Python (3) bindings are missing on RHEL/CentOS/EPEL 8 for the protobuf package (https://src.fedoraproject.org/rpms/protobuf). A bug request has been created on Bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=1765844), but as no status has

Re: Building the python executable statically with libpython*.a for better performance

On 2019-10-26 17:01, Neal Gompa wrote: On Sat, Sep 21, 2019 at 5:16 PM Miro Hrončok wrote: Hello, we've been recently approached by a colleague from Red Hat working on performance (CCed). According to their testing, Fedora Python performance could be improved by ~15% by building /usr/bin/pyt

Re: Python 3.8 porting help

On 2019-09-26 14:03, Richard Shaw wrote: On Thu, Sep 26, 2019 at 3:55 AM Petr Viktorin <mailto:pvikt...@redhat.com>> wrote: Actually, this is in FreeCAD code: FreeCAD-0.18.3/src/Base/swigpyrun.inl: PyObject *modules = interp->modules; Change "in

Re: Python 3.8 porting help

Actually, this is in FreeCAD code: FreeCAD-0.18.3/src/Base/swigpyrun.inl: PyObject *modules = interp->modules; Change "interp->modules" to "PyImport_GetModuleDict()" there. On 2019-09-24 16:33, Victor Stinner wrote: Hi, It sounds like an issue in SWIG which access directly the PyInterpreterS

Re: Python 3.8 porting help

Victor, do you know the answer here? Blender has the same issue: https://bugzilla.redhat.com/show_bug.cgi?id=1734980 (but I forgot to CC you there) On 2019-09-24 14:57, Richard Shaw wrote: I maintain FreeCAD for Fedora and there appears to have been a change in the API for how Python handles

Notes from the "Fedora Loves Python" session at Flock

Hello! I ended up running the "Fedora Loves Python" session at Flock. As the abstract says: > It seems that the Fedora ❤ Python initiative has recently become more > stagnated. It's not that Fedora no longer loves Python, but the > relationship has become rather boring, after several years > of

Re: pypy

Hi, On 2/19/19 3:14 PM, Antonette Caldwell wrote: Hi all I commented on https://bugzilla.redhat.com/show_bug.cgi?id=1673127 that I will be working on building pypy. So far, I was able to build pypy and pypy3 on rawhide, but this is my first time creating the package. I copied the spec from b

Re: Python packages with extras dependencies

On 2/5/19 12:44 AM, Eli Young wrote: Python packages can specify extras dependencies, which are sets of dependencies not required for core functionality, and which generally correspond to some feature. These can then be specified by downstream consumers of the package. For example, requests has

python3-debug: Should we use -Og rather than -O0?

Hi, I've been looking at documentation of these GCC flags: -O0 Reduce compilation time and make debugging produce the expected results. This is the default -Og Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization

Re: Future of Python 2.6 and Jython in Fedora

On 9/6/18 5:32 PM, Miro Hrončok wrote: In Fedora, we advertise "all the Pythons" are available and developers may use them with venv, virtualenv, tox. https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html Two of the interpreters we ship are quite problematic in thi

Re: Fedora 30 Self-Contained Change proposal: Make ambiguous python shebangs error

On 08/31/18 13:41, Miro Hrončok wrote: On 31.8.2018 13:30, Miro Hrončok wrote: On 31.8.2018 09:05, Igor Gnatenko wrote: On Wed, Aug 22, 2018 at 10:02 PM Ben Cotton > wrote: https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error     == Summary

Re: Why are we shipping debug builds of pythons?

On 08/05/18 14:01, Jan Kratochvil wrote: On Sun, 05 Aug 2018 13:39:58 +0200, Charalampos Stratakis wrote: Here we are referring to the python2-debug or python3-debug builds, which are just extra python builds that are compiled with the --with-pydebug flag Not just --with-pydebug:

Re: Python Bundled Wheels package

On 07/22/18 11:49, Miro Hrončok wrote: Hi Pythonistas and Fedora packagers. Recently I've realized we bundle too much wheels with our pythons + virtualenv package. That is unfortunate:  * we don't build those. stricly seeking, it's just a zip with python files in it, yet this is not permitt

Re: Are 3.6.x release candidates useful to find bugs?

On 05/21/18 14:43, Nick Coghlan wrote: On 21 May 2018 at 22:09, Charalampos Stratakis > wrote: > So, please, if you find any bugs in upcoming Python *3.6.x* release > candidates, let me know (or write to Łukasz directly)! If there are no > such re

Are 3.6.x release candidates useful to find bugs?

Hello! At PyCon US 2018, Łukasz Langa, the release manager for Python 3.7, told me that he'd like to collect data about Release Candidates for point releases (3.x.y). The idea is that if these aren't being tested and aren't revealing bugs, it would make sense to stop releasing them. So, plea

Re: PEP 394 update proposal: Allow changing the `python` command in,some cases

On 04/26/18 09:17, Nick Coghlan wrote: On 26 April 2018 at 05:22, Petr Viktorin wrote: If this goes through, in Fedora I would like to: - Create a "python" package containing *just* the /usr/bin/python symlink. This would be a subpackage of python2, and python2 would *suggest* it

PEP 394 update proposal: Allow changing the `python` command in,some cases

Hello, Upstream I submitted a [change to PEP 394] to allow distributions to change /usr/bin/python in some limited cases: - Users and administrators can, by a deliberate action, change python to invoke Python 3. (Activating a venv counts as such an action, but so would e.g. using alternates,

Re: Intent to orphan Python 2

On 03/23/18 17:57, Randy Barlow wrote: On 03/23/2018 07:23 AM, Petr Viktorin wrote: In case no one steps up, we'd like to start dropping Python 2 support from dependent packages *now*, starting with ported libraries on whose python2 version nothing in Fedora depends. (We keep a list of tho

Re: Intent to orphan Python 2

On 03/23/18 18:41, Toshio Kuratomi wrote: On Fri, Mar 23, 2018, 9:50 AM Petr Viktorin <mailto:pvikt...@redhat.com>> wrote: On 03/23/18 16:43, Toshio Kuratomi wrote: > > > On Fri, Mar 23, 2018, 8:13 AM Petr Viktorin mailto:pvikt...@redhat.com>

Re: Intent to orphan Python 2

On 03/23/18 16:43, Toshio Kuratomi wrote: On Fri, Mar 23, 2018, 8:13 AM Petr Viktorin <mailto:pvikt...@redhat.com>> wrote: On 03/23/18 15:15, Toshio Kuratomi wrote: > Something that occurred to me last night, rather than a conditional on > Fedora version, i

Re: Intent to orphan Python 2

On 03/23/18 15:15, Toshio Kuratomi wrote: Something that occurred to me last night, rather than a conditional on Fedora version, is there a macro that we could provide to mean python2 is available in this Fedora version?  That way packagers wanting to support their packages on the versions of p

Intent to orphan Python 2

be the ones doing it – at least not at the current magnitude". Here are the details. The current maintainers of python2 would like to "orphan" the python2 package in 2020 (~ Fedora 30): - Charalampos Stratakis (cstratak) - Tomáš Orsava (torsava) - Miro Hrnočok (churchyard) - Petr

Intent to orphan Python 2

be the ones doing it – at least not at the current magnitude". Here are the details. The current maintainers of python2 would like to "orphan" the python2 package in 2020 (~ Fedora 30): - Charalampos Stratakis (cstratak) - Tomáš Orsava (torsava) - Miro Hrnočok (churchyard) - Petr

Re: Intent to orphan Python 2

On 03/20/18 21:47, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Mar 20, 2018 at 04:11:46PM +, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Mar 20, 2018 at 03:28:23PM +0100, Miro Hrončok wrote: On 20.3.2018 14:45, Zbigniew Jędrzejewski-Szmek wrote: Indeed, I'm using those python packages like a

Re: Intent to orphan Python 2

On 03/20/18 14:45, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Mar 20, 2018 at 12:23:06PM +0100, Miro Hrončok wrote: On 20.3.2018 11:25, Zbigniew Jędrzejewski-Szmek wrote: to push the whole ecosystem. The proposed model of nipping python2 support at the edges is the same thing, in reverse. Fir

Intent to orphan Python 2

iners of python2 would like to "orphan" the python2 package in 2020 (~ Fedora 32/33): - Charalampos Stratakis (cstratak) - Tomáš Orsava (torsava) - Miro Hrnočok (churchyard) - Petr Viktorin (pviktori) - Iryna Schcherbina (ishcherb) - Michal Cyprian (mcyprian) - Bohuslav Kabrda (bkabrda) -

Re: Draft: Macros to tell what Python versions to package for

On 03/02/18 18:24, Jason L Tibbitts III wrote: "MH" == Miro Hrončok writes: MH> I expect it to be called for both 2 and 3 unconditionally. Hiding MH> the condition in the maro makes things too magical for me. I don't think that stance holds up well as we increasingly hide things in macros and

Re: Draft: Macros to tell what Python versions to package for

I like to use bconds, i.e. "%if %{with python2}". They're easy to override for local builds, allowing easy experimentation with, for example, dropping Python 2. I'd be happy if our official recommendation used bconds. If we want people to copy-paste something, let's make it good. Also, "with_p

No more automagic bytecompilation

I are drafting a Fedora change to eventually switch to doing the byte-compilation explicitly instead. Files in /usr/lib/pythonX.Y/ still get compiled automatically, of course. You can read the draft here: https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation -- Petr Vik

Re: Python 3.7's Deterministic pycs

On 02/01/2018 04:21 PM, Nick Coghlan wrote: On 1 February 2018 at 23:54, Petr Viktorin wrote: Honestly, I'm not sure we want to use this in Fedora. Is anyone here into reproducible builds, to make a better argument for this? I believe rpmbuild (et al) all set SOURCE_DATE_EPOCH i

Python 3.7's Deterministic pycs

NCHECKED_HASH, anyone doing it will have to remember to remove the corresponding .pyc file. Honestly, I'm not sure we want to use this in Fedora. Is anyone here into reproducible builds, to make a better argument for this? -- Petr Viktorin ___

Re: Django 2.0 released, and what it means to you

/wiki/User:Mrunge/Django20 Today, we proposed https://fedoraproject.org/wiki/Changes/Django20 and set it to Ready For Wrangler. I filed a review request for python2-django1.11: https://bugzilla.redhat.com/show_bug.cgi?id=1532541 -- Petr Viktorin ___ p

Re: pytest byte compiling its own files

7.src.rpm python-pyqtgraph-0.10.0-1.fc27.src.rpm python-pytest-timeout-1.2.0-3.fc27.src.rpm python-pytest-xdist-1.18.2-1.fc27.src.rpm python-wcsaxes-0.9-5.fc26.src.rpm -- Petr Viktorin ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Looking for package reviewers / sponsors for Thonny, Python IDE for beginners

om/enter_bug.cgi?product=Fedora&format=fedora-review -- Petr Viktorin ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Parselmouth Badge

pstream contribution affected Fedora. Should that be changed? -- Petr Viktorin ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Extension Build Question/Recommendation

robably too much effort for little gain. -- Petr Viktorin ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Package submission question

ally. Preferably, only bump library versions in Rawhide, and coordinate with the interested maintainers. (Automation for this is being worked on, in efforts related toModularity, but it's quite a big task.) -- Petr Viktorin ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Python 3 porting Bugzilla guidance

bug (see [Python 3 Bug Filing]). Then portingdb will eventually update. [Python 3 Bug Filing]: https://fedoraproject.org/wiki/User:Pviktori/Python_3_Bug_Filing -- Petr Viktorin ___ python-devel mailing list -- python-devel@lists.fedoraproject.or

Re: Package submission question

On 09/04/2017 03:37 PM, Miro Hrončok wrote: On 4.9.2017 15:34, Troy Curtis Jr wrote: On Mon, Sep 4, 2017 at 7:52 AM Miro Hrončok <mailto:mhron...@redhat.com>> wrote: On 4.9.2017 14:49, Troy Curtis Jr wrote: > > > On Mon, Sep 4, 2017 at 3:54 AM Petr Vik

Re: Package submission question

updated. In the meantime, I'll fix the rpmlint warnings I just found! That shouldn't be happening. What's your FAS username? If you can push the changes to another public Git repository (e.g. GitHub), that could be a workaround while we get Pag

Re: Modularity, container images, and the default Python stack(s)

On 08/25/2017 10:23 AM, Nick Coghlan wrote: On 24 August 2017 at 21:28, Petr Viktorin wrote: On 08/24/2017 12:22 PM, Nick Coghlan wrote: Stream names match the Platform module. We follow its policy here, even when it changes. Oh, interesting, I had that backwards (I thought the planned F27

Re: Modularity, container images, and the default Python stack(s)

On 08/24/2017 12:22 PM, Nick Coghlan wrote: On 24 August 2017 at 19:02, Petr Viktorin wrote: On 08/24/2017 10:13 AM, Nick Coghlan wrote: My current thinking based on that discussion is that we're actually going to need a module set that looks like this for F28+: * Platform Python (al

Re: Modularity, container images, and the default Python stack(s)

On 08/24/2017 10:13 AM, Nick Coghlan wrote: On 21 August 2017 at 19:46, Petr Viktorin wrote: On 08/18/2017 01:38 PM, Nick Coghlan wrote: Does that approach sound sufficiently plausible to folks that I can use it to provide feedback to the folks working on the modularity tooling as to the

Python 3.5.4 in Fedora 25

Hello, Python 3.5.4 for Fedora 25 is now waiting in Bodhi; see more info here: https://bodhi.fedoraproject.org/updates/python3-3.5.4-1.fc25 Please test and provide karma :) -- Petr Viktorin ___ python-devel mailing list -- python-devel

Re: Setting up a fedora-python pagure.io group

ions about this. -- Petr Viktorin ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Modularity, container images, and the default Python stack(s)

usible to folks that I can use it to provide feedback to the folks working on the modularity tooling as to the capabilities we think we'll need? That sounds like it would work. But yes, please talk to the Modularity WG to see if modules can be made to work that way. -- Petr Viktorin __

Re: ENOTIME

ptools python3-six python3-sqlalchemy python3-suds python3-tornado python3-urllib3 -- Petr Viktorin ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Naming policy for application vs library packages in Python

t; clauses in their naming guidelines. I think it makes sense to have something similar for Python, to help avoid confusion. That's a nice idea. I'll note that modules installed using Python's mechanisms (setuptools, flit, pip, etc.) automatically provide "python3di

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

change until it starts being necessary. Rebuilding lots of packages in EL6 is practically impossible, actually. However, some subset of commonly-used packages do have the python2- prefixed provides even in EL6. The very example above is misleading: EL6's packages do provide python2-devel.

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

ug filings. Iryna, could you draft a change? Another strategy we'll be using is not filing all the bugs at once: the plan is to file a few at first and learn from the reactions before doing the next wave. [0] https://fedoraproject.org/wiki/Mass_bug_filing -- Petr Viktorin

Re: To use or not to use: packaged flask

ged – one that doesn't include flask.cli yet. Generally, you're better off using a virtual environment and PyPI, unless you're making some software specifically for Fedora. Packages with native code aren't as much of a problem nowadays as they used to be, but if you stil

Re: Python 3.6 and blocking-by-default os.urandom()

reproduce this? On 08/08/2016 02:59 PM, Nick Coghlan wrote: On 8 August 2016 at 20:04, Petr Viktorin mailto:pvikt...@redhat.com>> wrote: On 08/08/2016 06:09 AM, Nick Coghlan wrote: Elaborating a bit further on the nature of the proposed Rawhide experiment, the cases

Re: Making sudo pip Safe

less automatically updated. I think it would be important for a change to --user by default to try to address this issue. But --user doesn't address the issue of updating either. -- Petr Viktorin ___ python-devel mailing list -- py

Re: Making sudo pip Safe

th Python 3's built-in isolation between different *versions* of Python, I think there's no problem with separating packages installed with `sudo pip` from the system Python and from a Python compiled from source. -- Petr Viktorin ___ pyt

  1   2   >