I don't want to repeat myself, please take a look at my wiki page .
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 be part of the SIG. My name is in the
member list  for quite a while but I guess that doesn't come with the
Thanks for adding me to python-sig.
If you have any further questions please replay to this message or write
me in private. These days I'm no longer very active on IRC because of my
I am looking to update Spyder-IDE to version 4.x  on rawhide and ran
into some issues. Spyder 4 introduces a few new dependencies are not yet
available in Fedora or have been retired. These dependencies are
qdarksuite, diff-match-patch and python-language-server.
qdarksuite is not necessarily a problem. It depends on qtsass and
helpdev. These three are fairly easily packaged .
diff-patch-match is already present in Fedora but has not been updated
for sometime by the looks of it. Although I have not tested if the
latest upstream version builds, I suspect this should not be a problem.
python-language-server (pyls), on the other hand, may be a problem. pyls
depends on several packages including jsonrpc-server, versioneer and
backports.functools_lru_cache in the simple configuration. The first two
packages are straightforward to build . However, lru_cache seems to
python2 only as far as I can tell. Furthermore, it was recently retired
in Fedora for the exact same reason .
How do I proceed? Can the SIG give me some pointers on how I can move
forward? Anyone has experience with packaging Pyls?
we are considering to add a %pycached macro to be used in the %files section:
We'd like to receive feedback. We plan to add it to rawhide and backport it to
all Fedoras + EPEL7+.
This will list:
Assuming the Python 3 version is 3.8.
The bytecode files are globbed, their presence is not checked.
This will fail:
error: %pycached can only be used with paths explicitly ending with .py
And so will any of this:
But this will work:
And it will generate the following globs:
When used with paths that include Python 3 version, it globs with the version:
While paths without version have less strict globs:
This will generate a warning in RPM build:
warning: File listed twice: /custom/__pycache__/foo.cpython-38.opt-1.pyc
However it ensures the optimized bytecode is there.
I'm wondering if there is a way to get the Python exception message via
From what I can see the web interface only shows the call stack but without a
specific exception there is not much I can do.
(I saw the exception message when a user created a bugzilla bug)
On 11. 12. 19 17:01, Stephen John Smoogen wrote:
> On Tue, 10 Dec 2019 at 20:24, Miro Hrončok <mhroncok(a)redhat.com> wrote:
>> Hey EPEL people.
>> We got a request to branch Python 3.7 foe EPEL 7:
>> Are there volunteers to make that effort? And if so, should this be done in EPEL
>> 8 first? And what about Python 3.8 in EPEL 7?
>> So many questions. So little time.
>> That said. If somebody want this, we (Python Maint) can help coordinate, but we
>> don't have the manpower to really maintain various Python versions in EPEL for
>> next X years.
> Honestly after all the work and pain it got to get python36 in
> EPEL7... I would prefer not to try that again.
Note that there is a big difference between maintaining a stack of various
python37-foo packages and maintaining the interpreter only.
> I think maintaining the
> version that is the base in RHEL-8 is going to be more than enough
> headaches and trying to keep up with the python of the year is not
> productive. I think that any volunteers should first make the versions
> of python37/38 in COPR and see if they have the volunteers and time to
> maintain it there.
That is true.
Hey EPEL people.
We got a request to branch Python 3.7 foe EPEL 7:
Are there volunteers to make that effort? And if so, should this be done in EPEL
8 first? And what about Python 3.8 in EPEL 7?
So many questions. So little time.
That said. If somebody want this, we (Python Maint) can help coordinate, but we
don't have the manpower to really maintain various Python versions in EPEL for
next X years.