I copied the python-crypto maintainers alias on this message, as well as
the maintainer aliases for the four packages that depend on it. This
message is just a quick analysis of what depends on
python-crypto/PyCrypto, and what it might take to retire the package if
that’s desired. Other than dr
For a proposed nose successor, pynose doesn’t seem to have gained much
community traction so far: it has seven stars on GitHub[1] (compared to
770 for nose2, which itself was never that widely adopted and has fewer
than ten dependent packages in Fedora); and the imperfect but fairly
useful reve
I patched python-signature-dispatch[1] and python-vecrec[2] so that they
now use flit-core. I’m glad you pointed out that they were using flit.
[1] https://github.com/kalekundert/signature_dispatch/pull/6
[2] https://github.com/kxgames/vecrec/pull/3
On 1/25/24 15:58, Maxwell G wrote:
On Thu J
I think I would just do something like this in %prep:
sed -r -i 's/^file:/# &/' tests/requirements.in
On Thu, Dec 28, 2023, at 11:41 AM, Mattia Verga wrote:
> While trying to update python-rpds-py I came across this commit:
> https://github.com/crate-py/rpds/commit/27d6caf11aac8170e2e9fd56042f05a
The assertRaisesRegexp alias was removed in Python 3.12, along with a number of
other previously-deprecated TestCase method aliases. You can search for it in
https://docs.python.org/3.12/whatsnew/3.12.html. Upstream should just use
assertRaisesRegex unconditionally unless they are trying to supp
Yes, please just build into Rawhide now.
On 7/6/23 9:20 AM, Michael J Gruber wrote:
Is the matrix bridge down? Anyways:
If I have a fix for a package which has just been merged (dblatex), should I
build it with target rawhide? I'm asking because mock sees py 3.12 only with
--enablerepo=local,
On Sun, May 28, 2023, at 8:03 PM, Orion Poplawski wrote:
> Is there a canonical way to bypass setuptools_scm? Sometimes one would
> like to build from a github tarball (e.g. for test data) but then
> setuptool_scm fails to detect a version.
Setting the environment variable SETUPTOOLS_SCM_PRETEN
You’re right that project.dependencies has numpy>=1.22.3[1], but
upstream is also pinning numpy versions in the build-system.requires
section[2] in the same manner as oldest-supported-numpy[3]. This is for
PyPI distribution purposes; we don’t need to build wheels that support
numpy versions old
Considering the rationale you’ve laid out, I don’t have any complaints
about deprecating %{pyproject_build_lib}. I’m indifferent to the
possible addition of a setuptools-specific macro, assuming the
setuptools build directory is expected to stop changing frequently.
I tested the proposed repla
Deprecating a non-leaf package does technically require a FESCo approved
Change[1]. Considering the upstream project has been archived since 2017
and deprecated since 2015, I would certainly favor deprecating
python-lockfile in Fedora.
[1]
https://docs.fedoraproject.org/en-US/packaging-guidel
The failure in pipx is because argparse-manpage[1], which is not in this
list, requires distutils at runtime.
+ /usr/bin/python3 scripts/generate_man.py
Traceback (most recent call last):
File "/builddir/build/BUILD/pipx-1.1.0/scripts/generate_man.py", line 7, in
from build_manpages.manp
This is the classic issue where the “un-built” package gets imported
instead of the “built” one in the buildroot that you are trying to test.
I had some luck executing the tests, but ran into a BLAS linking issue
that I did not have time to investigate fully. Please see
https://bugzilla.redhat.
The orjson package itself is written in Rust, so it’s probably best just to do
without orjson for the python-cattrs tests if you’re not inclined to go down
that rabbit hole.
That said, it would be great to have a python-orjson package in Fedora, and
I’ve considered attempting it but never found
On 7/7/22 05:38, Miro Hrončok wrote:
In the spirit of other packaging guidelines, I believe we should use
this instead:
%pytest -n %{_smp_build_ncpus}
I agree that this is more strictly correct.
Should I do this in a mass change? Not so many packages use pytest -n
auto in the spec:
I thi
At least python-language-server really is dead upstream[1], replaced by
python-lsp-server, which is a maintained community fork.
The python-pyls_black package isn’t usable without python-language-server, and
nobody has stepped up to migrate it to python-lsp-server in over a year[2], so
it’s loo
On 6/25/22 06:01, Miro Hrončok wrote:
Hello folks,
I've just orphaned python-chardet. I maintained it as a dependency of
requests, but requests use python-charset-normalizer instead now.
I’ve picked it up, as a few packages I maintain or care about do depend
on it.
I recommend any depende
Thank you for working on this! I’m excited that this approach turned out
to be reasonably practical. This update makes it vastly more practical
to deal with packages that use the hatchling backend. I’ve already
updated python-hatchling itself and a handful of other packages to use
the new featu
I’d like to find some reviewers to clear out my backlog of mostly-Python
packages. These vary from near-trivial to moderately complicated.
I’m happy to review packages in exchange. I’m particularly comfortable
with C, C++, and Python, but reviewing other kinds of packages is a
possibility. It
Ok, this is simple enough, and you’ve been looking for someone to help
for quite a while, so I’ll bite.
Someone will need to do the review:
https://bugzilla.redhat.com/show_bug.cgi?id=2059247
– Ben
On 2/23/22 19:44, Kelly Brazil wrote:
Hi team,
I am the developer of JC and Jello. JC is cur
I think this makes perfect sense. It would be generally helpful for the
reasons stated, and it’s hard to imagine any cases in which it could be
harmful.
– Ben
On 1/10/22 07:55, Miro Hrončok wrote:
Hello Pythonistas.
When we invented the %pyproject_buildrequires BuildRequires generator,
it g
It turns out that while a couple of packages I care about were actually
broken by the bump to 3.0, most of them were instead broken by the
update failing to install on F34[1].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=201
On 12/16/21 14:09, Ben Beasley wrote:
It looks like python
It looks like python-pytest-cov was recently updated to 3.0.0 in F35[1]
and F34[2]. I noticed this because, between my own packages and those
maintained through @neuro-sig, I saw a wave of FTBFS notifications from
Koschei.
Unfortunately, because packages commonly pin a particular major version
I know this pattern works in general, because I maintain several Python
packages in which it is used.
I tried modifying python-fixit to patch requirements.txt as you
described. I confirmed the line appeared in the “prepped” source as you
have written. Then I built it with mock and installed it
Almost all of the Python packages I maintain have something useful in the
GitHub archive that isn’t in the PyPI archive. I find that PyPI source
distributions commonly lack test suites and usually lack documentation. I
choose PyPI sources where all else is equal, but in a lot of cases using GitH
The section you linked says “See the following section to learn about
%py_provides.”
That following section,
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Automatic-unversioned-provides,
describes when and how to use %py_provides. It explains how the vast
majority of Pytho
!
- Ben
On 8/30/21 6:22 AM, Chandan Kumar wrote:
Hello Ben,
On Sat, Aug 21, 2021 at 12:36 AM Ben Beasley wrote:
Unless someone convinces me of another plan, I intend to retire
python-typer and python-typer-cli in F35 and Rawhide in one week
(2021-08-27).
I myself introduced these two packages
Unless someone convinces me of another plan, I intend to retire
python-typer and python-typer-cli in F35 and Rawhide in one week
(2021-08-27).
I myself introduced these two packages to Fedora quite recently
(https://bugzilla.redhat.com/show_bug.cgi?id=1964742,
https://bugzilla.redhat.com/show
I’d like to get python-xds-protos
(https://bugzilla.redhat.com/show_bug.cgi?id=1980041) reviewed so I can
update grpc to version 1.39.0 in Rawhide in time for Fedora 35.
This is a new dependency for grpc—a weirdly circular one that’s
ultimately generated from sources inside grpc, but is separa
In one week, or slightly later, I will update python-pyrsistent to
0.18.0 in Rawhide (https://bugzilla.redhat.com/show_bug.cgi?id=1977038).
This includes one minor API change; please see the release notes at
https://raw.githubusercontent.com/tobgu/pyrsistent/1b8e85ed0164a8f9908bee0524f9a9850c21c
29 matches
Mail list logo
