Closed #373.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/373#event-1469261044___
Rpm-maint mailing list
And until I changed it for openSUSE, it was never had the egg either. And
that's being introduced in openSUSE with v4.14. So, new name only.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
No existing RHEL version uses setup.py to build rpm's python bindings, that's
only done in Fedora. So no rpm .egg in RHEL.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai we were already done with the noise before more people started
chipping in =)
I was rather assuming that *RHEL* has also been shipping the `.egg` files,
meaning that the `rpm-python` name will be baked into RHEL 7 and thus around at
least somewhere for God knows how long, unless we
> Me, I'd rather fix the name in Fedora 26 too and move on.
I'm okay with this, but I think it's fine to just Let The Past Die(TM) and with
RPM 4.14 onward, we'll have the right name.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
I think everyone should really switch to `rpm` from `rpm-python` (or even to
not rely on it because rpm is not published on PyPI). My 5czk.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Here's my 5c from the POV that I'm the one who came up with the original
-python suffix:
Adding the separate setup.py had to do with the idea/intention of splitting the
python bindings into a separate repo/tarball, in which case the tarball
probably would've been called rpm-python. That of
"rather than blaming rpm developers for Newer! Better! Bestest! Python (and
depsolvers) changes."
Python didn't *change* anything here. rpm did: the name in the `setup.py` you
ship. That's it. That's the extent of the change that caused the problem. I'm
still baffled as to why it seems so hard
Correction: PEP 345 appears to have a Provides-Dist: tag to handle virtual
packages bundled together. Using existing functionality wisely (assuming
implemented) would seem to be the best way forward.
Providing two egg-info files to handle the change seems rather hacks.
--
You are receiving
@AdamWill I fail to see how 2 names is better than one, particularly since
there seems to be no already implemented mechanism within egg-info to deal with
multiple names (and the claim afaict is that the functionality is deemed
unnecessary).
--
You are receiving this because you are
Truly rpm-python should be split off to its own project in the eco system,
published to pypi, and whatever else is desired, rather than blaming rpm
developers for Newer! Better! Bestest! Python (and depsolvers) changes.
That was the original plan back in 2006 or so, just no round 'tuits.
RPM
I'm sort of reaching the point where I'm thinking it's just not worth trying to
explain it any more, especially since apparently trying to bring an RPM analogy
into the discussion has only made things *more* confusing, not less. But no,
there's no "duelling" going on. I only referred to RPM
@AdamWill so there is the problem of what I would call dueling package
managers, and it's unclear (particularly because of ever changing
incompatibilities in python) what solution(s) should be pursued by rpm.
By all means, use pypi (or apt or ...) if that is what one wishes. Blaming rpm
for
@n3npq There's nothing wrong from the RPM point of view. The problem is from
the python installed package index for tools like `pip` to process.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
FWIW, rpm permits virtual package names, where a Provides: is treated
identically to a package NEVR. This was deliberately (and incompletely) ripped
out of Obsoletes: in Fedora
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
@Conan-Kudo "Actually, what they did was just not specify it at all in
setuptools." - sure, that's what I meant by "just given up when 'rpm' didn't
work". I was positing that some obsessive nerds like myself would figure out
what the name actually was and use that, while some people would just
@n3npq "After reading #273, it isn't clear why a egg-info mechanism tied to
pypi"
egg-info isn't "tied to" pypi, just like RPM isn't "tied to" dnf or zypper or
yum or Fedora's repositories or SUSE's repositories or Red Hat's repositories.
egg is a "built distribution" format, just like .rpm is
> But as you say, that never previously did work, so anyone who's previously
> tried and not just given up when 'rpm' didn't work must surely have landed on
> 'rpm-python', like I did.
Actually, what they did was just not specify it at all in setuptools. As I said
before, a lot of
@Conan-Kudo Oh, I'm sure *everyone* who tries to express a dependency like this
tries the name 'rpm' first. I certainly did. :P But as you say, that never
previously did work, so anyone who's previously tried and not just given up
when 'rpm' didn't work must surely have landed on 'rpm-python',
@AdamWill The issue that I've been seeing is that people have been putting
`rpm` as the setuptools `install_requires`, which obviously never worked before.
In addition, many Linux distributions (RPM-based and not) didn't install the
Python bindings via `setup.py` and didn't provide the metadata
If the name isn't used (what I called "informative"), then there should be no
difference in loading behavior (unless there is some silly (imho) check on
metadata consistency, in which case 2 egg-info files is the only way to deal
with what has already been released).
The actual failure mode
I'm definitely only talking about Python concepts here. C concepts don't play
into all this *at all* since we're only talking about Python ecosystem stuff.
"If setup tools is constructing module paths from egg-info Name: directives
(which is rather deficient)"
No, it's not doing that. There is
The key issue here is "What is the failure mode?".
If setup tools is constructing module paths from egg-info Name: directives
(which is rather deficient) then there is no solution available (AFAICT) except
to feed a Name: directive in some alternative egg-info file.
If Name: is purely
BTW, there's a rather [cryptic
bit](https://setuptools.readthedocs.io/en/latest/setuptools.html#metadata) of
the setuptools docs that sort of suggests you might be able to use a `provides`
kwarg to `setup()`, so we could try something like:
setup(name='@PACKAGE_NAME@',
OK, let's both calm down a bit. I was just annoyed at running into this
entirely unnecessary problem while i was in a hurry last night. I agree that in
practical terms it's not a major disaster that's likely to affect lots of
people catastrophically. It's still *wrong*, though.
Let's take a
@AdamWill: If python setup tools and egg-info is actually using Name: strings
rather than verifying the a rurally dependency semantic (which is a directory
from which a module can be loaded), I'd professional suggest that python eggs
are (in the case of C "libraries" as you have chosen to call
Please stop focusing on my specific use case here. The point is, you're
providing a library, and its metadata for Python distribution purposes is
significant, and it's a really bad idea to just change its name in that
metadata purely for purposes of 'neatness' or predictability when you've
@AdamWill: if most of what you (or others) need from rpm-python is NEVRA
parsing, then just write your own (IMHO).
It's nearly impossible to supply a "standard" and pleasing API in either
library or binding API's, and the parsing is Very Not Hard (comparison is of
course trickier, but likely
No. You're wrong. Really, you're wrong. It's very simple to demonstrate. These
are the steps.
git clone https://pagure.io/fedora-qa/relvalconsumer.git
cd relvalconsumer
git checkout 1.1.0
sudo python setup.py install
Try that with an older `python2-rpm` installed, and it will
See edit.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/373#issuecomment-353669089___
Rpm-maint mailing list
> I know of several codebases in this nexus, actually, because there are a few
> things people commonly want to do that there is no good Python library to use
> for. The infamous example is parsing NEVRAs; there was a function for doing
> this in hawkey, but then someone decided to kill hawkey.
"Since we don't publish to PyPI for very obvious reasons, any reliance on
setuptools information was always hokey."
The document I linked above *specifically states that it is reasonable to
express dependencies on things that aren't in pypi*. In a section
titled...[Dependencies that aren't in
@AdamWill
In almost every distribution (excluding Fedora) that was using Python bindings,
they were _not_ using the setuptools build. In fact, to date, I have not
encountered any significant applications that declared `rpm` or `rpm-python` as
a dependency in setuptools because most
Here's a commit that had to write a whole extra function in its `setup.py` to
get around this:
https://github.com/rebase-helper/rebase-helper/commit/2f1401c0adfc139aa3ecc12cdc21086d2fe69ac9
which is not an approach I can easily take, because I want to share the same
requirements between
BTW, I'm around on Freenode and RH internal IRC (adamw on both) for anyone who
wants to talk about this in real time. Also tagging @Conan-Kudo and @ffesti as
the committers.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
No. No, not that either. The *code* works fine, if it actually gets run,
because the name of the module itself (`rpm`) has not changed. This is about
bits of Python-ecosystem infrastructure that allow for the expression and
checking of dependencies. Specifically, in my case, `setuptools` and
So the problem is the name of a directory on some Python loader search path?
Sounds like a symlink would fix the renaming ...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This isn't about package dependencies. It's about Python ecosystem
dependencies. These particular dependencies are read by setuptools/distutils,
and by tox.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
There's several ways to solve a renaming: pick you poison wrto your packaging
policy.
Add a Provides: for the F26 name to the F27 package (or vide versa).
You can also add a file dependency, or add a Newer! Better! Besetest! name to
both packages/modules.
--
You are receiving this because
https://github.com/rpm-software-management/rpm/commit/2797d00ecd224a59a8ca967f40240e827ff31c69
was an awful change. Please revert it.
It doesn't matter that you've never published to pypi; so long as you install
an egg-info file people will rely on its contents. I was expressing a
dependency
40 matches
Mail list logo
