On 11/30/2016 08:04 AM, Igor Gnatenko wrote:
Hi,
in short, it reads egg metadata and can generate Provides (which we
already do now), Requires (which I want to talk about) and Recommends
(which I don't care atm).
Let's take simple package -- aiohttp.
https://bugzilla.redhat.com/show_bug.cgi?id=1381750
As you can see, since some version multidict requirement was bumped to
= 2.0 and async_timeout requirement was added. Currently we specify
all requirements during initial package and usually without versions
which is breaking after some time.
So, let's try it (I will skip unrelated parts).
Before:
python(abi) = 3.5
python3-chardet
python3-multidict
After:
python(abi) = 3.5
python3.5dist(async-timeout)
python3.5dist(chardet)
python3.5dist(multidict) >= 2.0
Without more complicated packages (MNE, nipy, nilearn, moss) it's
getting much more harder since I have there 10+ deps.
We can't really track all changes in upstream code, so if we will
enable dependency generator, it will do this work for us. Note that we
can't just enable it in RPM, because it will break a lot of packages
due to:
* missing requires in egg metadata
* extra requires in egg metadata (e.g. windows-modules)
I would propose plan:
1. Create macro which will enable/disable depgen (e.g %python_enable_depgen)
That would be cool!
2. Start enabling depgen and porting things (somehow reuse
portingdb.xyz probably?) and submitting patches upstream
While portingdb is open source and you can definitely set up a new
instance, I think that would be an overkill. Whether a package supports
Python 3 or not is highly relevant to other packages, since they depend
on one another.
However, whether a package manually lists its Requires or uses a script
to do that is not relevant to other packages, therefore I don't see the
benefit of a portingdb portal here.
3. In 1-2 releases I hope we can use it for major amount of packages
4. Enable depgen by default in RPM, add disabling depgen for remaining packages
I don't think the depgen should be enabled by default, at least not in
the foreseeable future. IIRC it's not that well implemented—e.g. I
believe it doesn't read requirements.txt for example (but I might be wrong).
There will be a lot of cases where the generated requirements are
incomplete, or contain unnecessary entries, etc. I think it should
remain an opt-in.
Regards,
Tomas
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
