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

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

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,

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

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

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:

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.

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

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:

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

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 --

Re: Draft of New Python Packaging Guidelines - 0.3

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! Below is a draft of new Packaging G

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-08-11 14:19

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, and not all

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 date

Draft of New Python Packaging Guidelines - 0.2

of the 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

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 error

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: 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

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.io, which

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 add mic

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

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

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

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

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

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 > proto

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 &quo

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

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

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 >

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

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

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

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     ==

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

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 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,

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 <pvikt...@redhat.com> 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, a

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 those

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

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.

Intent to orphan Python 2

f 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) - David Mal

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,

No more automagic bytecompilation

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 Viktorin

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 <pvikt...@redhat.com> 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) a

Python 3.7's Deterministic pycs

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 ___ python-devel mailing list -- python

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

/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 ___ python

Re: pytest byte compiling its own files

hon-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: Parselmouth Badge

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: Package submission question

tal Error (500)" in response. I am using the https repo url, and have cloned on another machine to ensure the urls are publically available. I guess that sounds like a thing that needs a report at https://pagure.io/fedora-infrastructure/issues I've reported it: https://pagure.io/fedora-infrastructure/issue/6332 -- 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)

On 08/25/2017 10:23 AM, Nick Coghlan wrote: On 24 August 2017 at 21:28, Petr Viktorin <pvikt...@redhat.com> 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 backwa

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 <pvikt...@redhat.com> 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 f

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 <pvikt...@redhat.com> 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 modu

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: Modularity, container images, and the default Python stack(s)

ack 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 ___ python

Re: ENOTIME

-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

e 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 "python3dist(name)". If we write new guidelines, I think we should promote that

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

eing 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. -- Petr V

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

lies to all mass bug 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_

Re: To use or not to use: packaged flask

sk.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 still run into trouble, we'll be happy to help :) -- Pet

Re: Making sudo pip Safe

olation 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 ___ python-devel mailing list -- python

Re: Python 3.6, Fedora, and the "C" locale

to go ahead, make a patch and put it on Bugzilla, or draft a Fedora Change page, please go ahead! -- Petr Viktorin ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: [RFC] RPM's Python dependency generator

CCing Michal from the pyp2rpm project, so that everyone knows he's aware of the discussion here. -- 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) packaging for EPEL 7: hddfancontrol

it provide python3*-daemon? Is that a reasonable course of action here? Any other suggestions besides just using Copr? Hello, Have you contacted the EPEL maintainers of python-daemon? I think those are the people that will give you the best advice around python-daemon in EPEL. -- Petr Viktorin

fedoralovespython.org

https://fedoraproject.org/wiki/User:Dhanesh95/SIGs/Python#Python_Features [2] https://fedoraproject.org/wiki/Marketing/Python_brochure [3] https://github.com/developer-portal/content/pull/159 [4] https://github.com/developer-portal/content/pull/156 [5] https://github.com/developer-portal/cont

Re: PEP: Distributing a Subset of the Standard Library

standard library directory that included: - a relative file path to stat to indicate that the optional module is installed - an import error message to raise if its not found The proposal evolved from a similar idea; after that I realized an extra "fallback file" in the stdlib directory is enough

Re: PEP: Distributing a Subset of the Standard Library

all Python modules to use that info in their packages. The discussion linked in the PEP draft contains lots of info about the status quo and opinions of Python core developers. -- Petr Viktorin ___ python-devel mailing list python-devel@lis

Re: Renaming python to python2

hon.org/dev/peps/pep-0394/ [linux-sig]: https://mail.python.org/mailman/listinfo/linux-sig -- Petr Viktorin ___ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: Automatic Provides: Discussion summary and plan

t setup.py can't express, strive to add them to future versions of the upstream packaging format. - For the far future, perhaps start getting rid of spec files: teach Koji to generate them, and stop storing them in dist-git. Helper macros stay orthogonal -- pyp2rpm would just need to learn to use

Re: Python 3.4 for Fedora 24+

cate that review is not needed in certain situations where a different version of an existing package is being added. * https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Package_Review_Process * https://fedorahosted.org/fpc/ticket/637 -- Petr Viktorin

Re: [Python-SIG] Self-Introduction: Tim Orling

sions. I'm not going to clutter python-dev with it anymore. No more negative energy. Life is good. Well, python-devel is the right list for this post. Sorry for the misunderstandings earlier. -- Petr Viktorin ___ python-devel maili

Re: Automatic Provides: Discussion summary and plan

On 08/12/2016 03:17 PM, Jason L Tibbitts III wrote: "PV" == Petr Viktorin <pvikt...@redhat.com> writes: PV> The magic worries me. It seems like if these macros were finished, PV> you'd be about the only person capable of maintaining them. I don't think so. Ther

Re: Automatic Provides: Discussion summary and plan

instead. I don't think the end goals – not having to write a spec at all, or write an ideal spec – are as important as the debugging experience. But, that's all just my view; I have no intentions of hindering the project, and I encourage anyone involved with RPM macros to study it and see wh

Re: Python 3 porting: 50% done in Rawhide 

On 08/11/2016 04:03 PM, Justin W. Flory wrote: On 08/11/2016 09:48 AM, Petr Viktorin wrote: Hello, As of now, http://fedora.portingdb.xyz shows that we are 50% done porting Fedora packages to Python 3. This is a big magic milestone; if you're looking for a reason to celebrate

Python 3 porting: 50% done in Rawhide 

ra-update.yaml] https://github.com/fedora-python/portingdb/blob/master/data/fedora-update.yaml [contribute] http://fedora.portingdb.xyz/howto/ -- Petr Viktorin ___ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Automatic Provides: Discussion summary and plan

with the f26 plan early. # Plan for Fedora 26: * All Provides will be regenerated in the regular Fedora 26 mass rebuild * Change Python guidelines so the %{buildrequires_pythonX_dist} macros are now encouraged. -- Petr Viktorin ___ python-devel

Re: [Python-SIG] Self-Introduction: Tim Orling

rgs/IronLanguages/people [6] https://github.com/robotframework/robotframework/graphs/contributors -- Petr Viktorin ___ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: Reg- binclock porting from python 2 to python 3

sponsive_package_maintainers -- Petr Viktorin ___ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org