Re: Rawhide python-rpm-generators news: small speedup + %python_provide not needed in most cases
Nice job, Miro!
Thanks a lot for working on this.
On Fri, Apr 3, 2020 at 8:45 PM 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 Lua macro, instead of by
> executing a Shell script. This is a bit faster especially for packages with a
> lot of files. For 10 000 files in one package, the speedup is roughly from ~80
> to ~2 seconds (time of the entire package build incl. creating the files from
> a
> Python script). That is a lot, but most of the real packages have much less
> files, so I am afraid you won't feel it.
>
>
> More importantly, %python_provide is not needed for package names.
> Until now, we needed to this:
>
> %package -n python3-foo
> ...
> %{?python_provide:%python_provide python3-foo}
>
> This adds automatic provides "python-foo" (and since recently, also
> "python38-foo" for forwards/backwards compatibility with EL). This now happens
> automagically. Any package called "python3-..." will have those provides added
> implicitly by the Python generators when they are in the buildroot
> (python3-devel brings those in, so for Python packages this means always).
>
> This automation was possible due to the speedup mentioned above, doing it the
> pre-RPM.16 way would be very slow, because the generator is called for every
> packaged file (which is still the case now, but it can now be a Lua macro).
> The
> ~2 seconds from above include this new feature.
>
> There are 2 cases where manual %python_provide calls are still needed:
>
> 1. Metapackages without files
>
> No files => no dependency generator. (I recommend to %ghost the
> dist-info/egg-info directory in such packages to workaround this -- we plan to
> add more good stuff regarding Python [extras] that will require this anyway.)
>
> 2. Virtual provides
>
> The dependency generator can see the (sub)package's name, but not any other
> virtual provides. When you do:
>
> %package -n python3-%{pypi_name}
> Provides: python3-%{legacy_name} = %{version}-%{release}
>
> You are still supposed to add:
>
> %{?python_provide:%python_provide python3-%{legacy_name}}
>
> (Also note that %python_provide adds obsoletes for older python-foo versions,
> that was useful when we renamed everything from python-foo to python2-foo and
> when we changed the "default" from python2- to python3-. We are keeping the
> Obsoletes in the macro (for now), but I have decided to not automatically
> generate the Obsoletes based on the package name. A) I don't consider them
> really needed in Fedora 33 any more and B) an idea of implicit obsoletes
> doesn'T
> sound very intriguing to me. This is a decision that may be revisited later if
> it's bringing unforeseen trouble.)
>
> You don't need to to actively remove the macro from your spec files, it does
> no
> harm. If you prefer to maintain a single spec, keep it there until Fedora 32
> goes EOL (and EPEL 8 if that's your target). The guidelines always recommended
> using it the safe way (%{?python_provide:...}), so even if it ceases to exist
> in
> the future, it can remain in specs. There is no plan to remove it in any near
> or
> distant future, as it is still needed for the virtual provides. The generators
> also use it internally (for DRY and consistent results).
>
> If you'll get into trouble because of this, let us know and we'll fix it.
>
> I'll make a note for myself to update the Python packaging guidelines.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Updating pytest to 5: ~30 packages FTBFS
These 2 packages will break: python-pikepdf-1.7.0-2.fc32.src: (python3dist(pytest) >= 3.10.1 with python3dist(pytest) < 5) python3-pytest-relaxed-1.1.5-1.fc32.noarch: python3.8dist(pytest) < 5 On Thu, Jan 2, 2020 at 5:09 PM Miro Hrončok wrote: > > Hello, > > I'd like to get pytest updated to 5.x in rawhide. > > https://src.fedoraproject.org/rpms/pytest/pull-request/15 > > Several deprecated things were removed from that version and 31 packages fail > to > build from source with pytest 5 (while building fine with pytest 4). > > > The packages are built in: > > http://copr.fedorainfracloud.org/coprs/churchyard/pytest-4/ > http://copr.fedorainfracloud.org/coprs/churchyard/pytest-5/ > > I would appreciate your help with fixing the packages. > > > > Several notable packages: > > scipy fix: https://src.fedoraproject.org/rpms/scipy/pull-request/15 > python-requests upstream fix: https://github.com/psf/requests/issues/5304 > > python-ipyparallel and > python-daskbuild somehow weirdly, maybe they will finish. > > python-pytest-* - there might be some newer versions available that work > > > > All packages: > > Maintainers by package: > ansible kevin toshio wzzrd > fabric orphan > pylast peter > python-atomicwrites mathstuf mbaldessari > python-beanbag sochotni > python-behavechurchyard pschindl > python-billiard fab mrunge ngompa pingou pjp rmarko sundaram > python-colcon-bazel cottsay > python-dask qulogic > python-flask codeblock fcami hguemar hushan > python-flask-caching lbrabec > python-flask-sqlalchemy hguemar kumarpraveen pjp ralph sundaram tflink > python-hpack eclipseo > python-html5lib churchyard pjp sagitter salimma sundaram > python-invokepghmcfc > python-ipyparallel ellert > python-lz4 jgu orion > python-mako abompard bowlofeggs cverna ignatenkobrain kylev lmacken > python-mdp zbyszek > python-paramiko athmane ignatenkobrain ivazquez orion pghmcfc sgallagh > python-pdir2 carlwgeorge > python-pyrsistentdecathorpe devrim itamarjp > python-pytest-covcstratak orion ttomecek > python-pytest-faulthandler dkrejci lbalhar > python-pytest-lazy-fixture ankursinha > python-pytest-relaxed athmane > python-pytest-xdist swt2c > python-requests abompard cstratak jcline ralph sagarun > python-testinfra wakko666 > python-whitenoisepiotrp > scipycstratak jspaleta orion tomspur ttomecek > > Packages by maintainer: > abompard python-mako python-requests > ankursinha python-pytest-lazy-fixture > athmanepython-paramiko python-pytest-relaxed > bowlofeggs python-mako > carlwgeorge python-pdir2 > churchyard python-behave python-html5lib > codeblock python-flask > cottsaypython-colcon-bazel > cstratak python-pytest-cov python-requests scipy > cverna python-mako > decathorpe python-pyrsistent > devrim python-pyrsistent > dkrejcipython-pytest-faulthandler > eclipseo python-hpack > ellert python-ipyparallel > fabpython-billiard > fcami python-flask > hguemarpython-flask python-flask-sqlalchemy > hushan python-flask > ignatenkobrain python-mako python-paramiko > itamarjp python-pyrsistent > ivazquez python-paramiko > jcline python-requests > jgupython-lz4 > jspaleta scipy > kevin ansible > kumarpraveen python-flask-sqlalchemy > kylev python-mako > lbalharpython-pytest-faulthandler > lbrabecpython-flask-caching > lmackenpython-mako > mathstuf python-atomicwrites > mbaldessari python-atomicwrites > mrunge python-billiard > ngompa python-billiard > orion python-lz4 python-paramiko python-pytest-cov scipy > orphan fabric > peter pylast > pghmcfcpython-invoke python-paramiko > pingou python-billiard > piotrp python-whitenoise > pjppython-billiard python-flask-sqlalchemy python-html5lib > pschindl python-behave > qulogicpython-dask > ralph python-flask-sqlalchemy python-requests > rmarko python-billiard > sagarunpython-requests > sagitter python-html5lib > salimmapython-html5lib > sgallagh python-paramiko > sochotni python-beanbag > sundaram python-billiard python-flask-sqlalchemy python-html5lib > swt2c python-pytest-xdist > tflink python-flask-sqlalchemy > tomspurscipy > toshio ansible > ttomecek python-pytest-cov scipy > wakko666 python-testinfra > wzzrd ansible > zbyszekpython-mdp > > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list
Re: Python packages with extras dependencies
In Rust we have similar problem (we have "features" than "extras") and we always package them as a subpackages. https://src.fedoraproject.org/rpms/rust-serde/blob/master/f/rust-serde.spec rust-serde-devel rust-serde+alloc-devel rust-serde+default-devel rust-serde+derive-devel rust-serde+rc-devel rust-serde+serde_derive-devel rust-serde+std-devel rust-serde+unstable-devel And the dependencies for all those subpackages are automatically generated. We could do the same with Python. On Tue, Feb 5, 2019 at 1:57 AM Miro Hrončok wrote: > On 05. 02. 19 0:44, 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 has an entry in extras > called security[1], which currently adds requirements of python packages > pyOpenSSL >= 0.14, cryptography >= 1.3.4, and idna >= 2.0.0. A downstream > consumer that wants to use this would add a dependency on > requests[security]. > > > > From what I can tell, the current practice in Fedora packaging is to > ignore these. This simplifies packaging Python modules that have extras > specified, but ultimately pushes the specification of those dependencies > down into every consumer of the package, whether users or other packages. > > > > As an example of this, I currently maintain the python-dns-lexicon > package, which provides a common CLI and API for various different DNS > providers. Some of the providers have additional dependencies that are > necessary to function, and which are specified as extras. The Plesk > provider, for example, also requires python-xmltodict[2]. In line with what > appears to standard practice, extra dependencies are not currently > installed with the broader python-dns-lexicon package. If, however, a user > or dependent package wants to utilize the Plesk functionality of > python-dns-lexicon, they now need to know that python-xmltodict needs to be > installed, and will need to check whenever the package updates as to > whether or not that has changed. > > > > How should we be handling this? Right now, it seems that most packages > follow this behavior of punting on the responsibility to package consumers. > Should this continue? If not, how should we handle things? Should we just > include all extras dependencies in the parent package? Alternatively, > should we have dummy/meta subpackages for extras that require the parent > package as well as any extras dependencies (e.g. python-dns-lexicon-plesk > would require python-dns-lexicon and python-xmltodict)? > > This (metapackages) is what I've done in python-trimesh: > > > https://src.fedoraproject.org/rpms/python-trimesh/blob/master/f/python-trimesh.spec#_62 > > https://src.fedoraproject.org/rpms/python-trimesh/blob/master/f/python-trimesh.spec#_86 > > I'd still consider this on case by case basis instead of developing a > general > solution, sometimes a simple Recommends works. Sometimes, it's more > complicated. > > I'm CCing packaging and python to get more attention to this, but please > keep > the discussion on devel, so it's not shattered. > > > > [1]: https://github.com/requests/requests/blob/v2.21.0/setup.py#L105 > > [2]: https://github.com/AnalogJ/lexicon/blob/v3.0.6/setup.py#L101 > > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > python-devel mailing list -- python-devel@lists.fedoraproject.org > To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org > ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
python2 doesn't require setuptools anymore
So finally this will force people to put proper BRs :) -- Forwarded message - From: Date: Wed, Aug 29, 2018, 07:06 Subject: python-parse's builds started to fail in Fedora rawhide To: Notification time stamped 2018-08-29 05:06:26 UTC python-parse's builds started to fail in Fedora rawhide https://apps.fedoraproject.org/koschei/package/python-parse?collection=f30 -- You received this message due to your preference settings at https://apps.fedoraproject.org/notifications/ignatenkobrain.id.fedoraproject.org/email/56304 -- -Igor Gnatenko ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: RFC: Drop python-rpm-generators for the subpackage to be built as part of the rpm package itself
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2018-01-11 at 10:37 -0500, Neal Gompa wrote: > Hey, > > As I was looking at the rpm.spec and fixing up a small bit of the > build for the Python bindings, it occurred to me that we have left > python-rpm-generators out of sync with rpm. > > I'm wondering if it even makes sense to keep that as a separate source > package, and instead build the python3-rpm-generators subpackage from > the main rpm package. I'd much rather do that as it makes it much > easier to keep everything in sync. > > We inherited the split from Fedora, who did it for their failed > modularity effort to try to make a base system environment that was > only C and shell but also contain the rpm-build package (I didn't say > it made sense...). From the point of view of Mageia, who is unlikely > to attempt what Fedora is doing, I'm not sure there's a particular > value in doing so. I was not even particularly enthused about this > when Fedora did it... > > Insofar as bytecompilation issues are concerned, we should probably > rename the file on install to not have the .py suffix, so that the > Python interpreter doesn't consider it as something to bytecompile. > That will allow us to avoid the issues that necessitate python -> rpm > -> python rebuilds. > > What do you all think? To be honest, I would like to separate even upstream to its own repository. I don't think it makes sense to keep it part of RPM itself. CCing python SIG and RPM maintainers for their feedback. - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpbS2oACgkQaVcUvRu8 X0wuQA//c/dzTdVrqe9KSfW2kapfFwhYwJvHGH2aD5WZNxqkcYSvwnXh1tUzfEtO GYwedYcEneTPpoI4IbHq+v7s5ds7BEWdlI6BNF/dlQOk98J+8HSXeikoqoC9g845 nTwwvJh6d7la0O0Jc2XRIHgqw/Flw5YhtQPyfo5jCvEX42LsMGmRvpVRJsVftvud XFFFTVAgCS2kJTAiygiRx2vkx/adtcucmAOBGG9TAUnoEH4glHSyslyJFyWo/M2K GDgxXfqnaseuiHPkQ3S4hgw+oBxuHxQ6GMB2n/ktQqY9XVYy9JODBG77VgLrjt+G kw/h0pfHetIN8mafrvkPXHmF7d4fS/CCS/W47BUm+f9qRiyw1Mpd48XugL+1IWHM 3/X1H1uWXNBDJKevVZoXkPO4qYV6shqXHAwtWBlTqnoH6UmM08Ob/Xvd+BLgU8wp 1Fu03KrmD8swBo0JtLsaecypYEEmeK5FmgVtl8AiCsoLi65Qwq/4RA3C6dA1AMCo aROpHrA1oDexq6fW1bQPhXIjzJtVPGC85+aomKPkVRM4+Fk6ceUrTJ0tEAA2kCkw mLhh6sTsMrq4epK3buM6n/brRLwffsrLO4cESeWBqlPKnfYuinEt3yJglDhWHaaS 132dyoIx7Tc4VM0Fe7sKay9WgwbpK80eom/Y4hSas30vVnSTE3o= =Sm5k -END PGP SIGNATURE- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Should Python 3 macros us UTF-8 locale?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, 2017-06-01 at 17:56 +0200, Miro Hrončok wrote:
> Hi Pythonistas.
>
> Regarding our Python 3 C.UTF-8 locale coercing [1], aka PEP 538 [2].
>
> As you probably know, we build RPM packages with the C locale. So
> everytime we use python3 in the spec file, the coercing message is
> shown. This can be more problematic than just spamming the build
> logs,
> see for example the related rpmlint bug [3][4].
I would prefer to fix mock once which will fix not only python builds,
but others as well!
>
> Our macros, such as %{python3_sitelib}, %{python3_version} etc. all
> call
> python3 and generate the warning. Should we "fix" our macros to set
> the
> LANG to C.UTF-8?
>
> If we change the %{__python3} macro entirely, we might get rid of all
> of
> those warnings and we will workaround the fact that we build RPM
> packages with the C locale. On the other hand the packager would not
> be
> able to set a desired locale because it will always be overwritten:
>
> # The crazy test suite needs Czech locale
> LANG=cs_CZ.utf8 %{__python3} -m pytest
>
> Will become:
>
> LANG=cs_CZ.utf8 LANG=C.utf8 /usr/bin/python3 -m pytest
>
> So I would not do that.
>
> But we can change all other macros in
> /usr/lib/rpm/macros.d/macros.python3 to set the UTF-8 locale. Would
> that
> be wise? Desired?
>
> Any thoughts?
>
>
> [1] https://fedoraproject.org/wiki/Changes/python3_c.utf-8_locale
> [2] https://www.python.org/dev/peps/pep-0538/
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1457786
> [4] https://bugzilla.redhat.com/show_bug.cgi?id=1436345
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to python-devel-leave@lists.fedoraprojec
> t.org
- --
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlkwbP0ACgkQaVcUvRu8
X0xZnw/9EGT6r12y4wcITPH+Y8SYCkcKVDsIIofhbZLFP1f+bAjYVjnVWccn5Nih
uFcXbHXcHp+jji+gAxrG44tdZS212aMIZ57cqEIx7xlG/qf5z1Vx+ZOMDhrP61lx
l+MAvoCI0fGdVGX5R7qZX1Vun6K6E93viAyjSTn+liCeJr9F0PxJsVC8StNvBk2c
2ZER6lgAQ0Nck+Y7K4oN7l09uHuBmxMCDcOXGBHcl5M3Mwh65WZncY162h4nQc2V
X7+Gyq83kx1Ya/LIOuG2rM74QcaaQ4IaoI2FBVj8DWFdgF/goYFOFfd3HwqVPVEZ
TJ8KV3XlnkaMqE9ysvKw3FZErUAxkqVy18OlkdEVFv7AQCx/eZqfTGrgurqCUYZQ
FB7ZjYjdNSyu5RFiOKXJWbUTgfHKe6BugVsvcajbpW493A5iOpnurMEuEL0w5ucp
KRnMvmEKq69iJ+NqXcGJRBIYN28RjAoxoydXcV5heVkMab4HJoLOhp0HdEsteFiD
l/+YcHG7HkERiKG6AxjJRjz42v8rgpP14fRnAQb+yKVfqQ5u5Ld0jsEIs+ST1Pwl
aHqoC2QEYPsL1rDEnOiWG2J61giUd0/pXJMMhE9Ki5yWtgsImnpqqHXAPn/accRR
5EjYFDFhP5PH3BkaowCjgzehjUBpHQwcCn8qHmqWN5AZoG3WLb0=
=K+2G
-END PGP SIGNATURE-
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: ipykernel to recommend stuff?
On Wed, Apr 5, 2017 at 7:13 AM, Nick Coghlan wrote:
> On 5 April 2017 at 05:00, Miro Hrončok wrote:
>> Hi,
>>
>> I got this idea that the python{2,3}-ipykernel packages could recommend some
>> modules useful to use in the Jupyter Notebook.
>>
>> Recommends:
>> * numpy
>> * matplotlib
>>
>> Not sure if should be recommended or suggested:
>> * pillow
>> * scikit-image
>> * scikit-learn
>> * scipy
>> * statsmodels
>> * sympy
>> * pandas
>
> I'd move `pandas` into the "recommends", but `suggests` seems
> reasonable to me for the others.
Note that Suggests are "ignored" by DNF, it is used only for
"favoring" packages if there are multiple provides.
>
> Definite +1 from me for the general idea though.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
--
-Igor Gnatenko
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Packages FTBFS with Python 3.6
On Wed, Dec 28, 2016 at 8:25 PM, Igor Gnatenko wrote:
> On Wed, Dec 21, 2016 at 12:18 AM, Miro Hrončok wrote:
>> Hi all,
>> We've recently tried to rebuild all Python packages with Python 3.6.
>> However, we currently have bunch of packages that simply fail to build.
>>
>> As the list contains >200 packages, it would be very helpful, if you
>> (package maintainers) could help us solve the issues, as we cannot go one by
>> one to investigate the issue.
>>
>> I've attached the list of failed packages (failed.txt). You can search Koji
>> to find out, what went wrong. Sometimes, it's just missing dependency. That
>> dependency should be on this list as well. If it is not, maybe we lost it,
>> please tell us if that's the case. Maybe the dependency is circular and
>> something needs to be bootstrapped. If you need provenpackager powers, let
>> me know.
> I've fixed python-smartcols and python-behave..
>
> Attaching current rawhide/koji packages which depend on python 3.5
> instead of 3.6 still.
Let me update a list of packages (don't worry if you know about this
and it depends on some other fixes, just want to make some regular
updates of status):
PACKAGEMAINTAINERS
lcgdm aalvarez
adev
andreamanzi
rocha
python-characteristic tomprince
python-deapzbyszek
python-django-admin-honeypot echevemaster
python-django-avatar kumarpraveen
python-django-countriesbkabrda
python-django-filter bkabrda
churchyard
lbazan
python-django-jsonfieldgermano
python-django-notifications-hq suanand
python-flower jcline
python-gensim besser82
python-kdcproxynalin
npmccallum
python-mdp zbyszek
python-mossignatenkobrain
python-nipyignatenkobrain
python-os-brickapevec
jpena
jruzicka
python-oslo-messaging apevec
gchamoul
markmc
ndipanov
python-oslo-middleware apevec
gchamoul
python-oslo-versionedobjects apevec
hguemar
python-profilehooksbkabrda
python-pyopenclignatenkobrain
python-recommonmarkjujens
python-repoze-who-plugins-sa lmacken
python-sphinxcontrib-programoutput itamarjp
zbyszek
rb_libtorrent fale
root ellert
shogun besser82
lupinix
sympy cbm
jjames
> --
> -Igor Gnatenko
--
-Igor Gnatenko
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Packages FTBFS with Python 3.6
On Wed, Dec 21, 2016 at 12:18 AM, Miro Hrončok wrote: > Hi all, > We've recently tried to rebuild all Python packages with Python 3.6. > However, we currently have bunch of packages that simply fail to build. > > As the list contains >200 packages, it would be very helpful, if you > (package maintainers) could help us solve the issues, as we cannot go one by > one to investigate the issue. > > I've attached the list of failed packages (failed.txt). You can search Koji > to find out, what went wrong. Sometimes, it's just missing dependency. That > dependency should be on this list as well. If it is not, maybe we lost it, > please tell us if that's the case. Maybe the dependency is circular and > something needs to be bootstrapped. If you need provenpackager powers, let > me know. I've fixed python-smartcols and python-behave.. Attaching current rawhide/koji packages which depend on python 3.5 instead of 3.6 still. -- -Igor Gnatenko dnsyo elastic-curator gerrymander google-api-python-client graphite-api hgsvn lcgdm libcec libproxy libuser netstat-monitor openwsman pcs pdc-client python3-bsddb3 python3-cherrypy python-acme python-adal python-beanbag python-blosc python-cassandra-driver python-castellan python-ceilometerclient python-cerberus python-characteristic python-congressclient python-cursive python-deap python-dill python-django-admin-honeypot python-django-avatar python-django-countries python-django-filter python-django-formtools python-django-jsonfield python-django-model-utils python-django-notifications-hq python-django-openstack-auth python-django-pyscss python-fastimport python-flask-migrate python-flask-script python-flower python-gensim python-gerritlib python-hglib python-k8sclient python-kdcproxy python-keystonemiddleware python-lazr-smtptest python-magnumclient python-manilaclient python-marrow-mailer python-mdp python-microversion-parse python-more-itertools python-moss python-netdiff python-nipy python-openstacksdk python-os-brick python-osc-lib python-os-client-config python-oslo-cache python-oslo-context python-oslo-db python-oslo-log python-oslo-messaging python-oslo-middleware python-oslo-policy python-oslo-reports python-oslo-service python-oslo-versionedobjects python-oslo-vmware python-photutils python-profilehooks python-prov python-pyopencl python-recommonmark python-repoze-who-plugins-sa python-rows python-sphinxcontrib-programoutput python-sphinxcontrib-spelling python-statsd python-structlog python-swiftclient python-tackerclient python-tosca-parser python-troveclient rb_libtorrent root rpy shogun sympy ___ 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
On Wed, Nov 30, 2016 at 2:53 PM, Tomas Orsava wrote:
> On 11/30/2016 02:44 PM, Neal Gompa wrote:
>>
>> On Wed, Nov 30, 2016 at 8:41 AM, Tomas Orsava wrote:
>>>
>>> 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.
>>>
>> According to various Python people, we're not actually supposed to
>> read requirements.txt. That file is explicitly designed for people to
>> individualized deployments. The proper place to get this information
>> is from the egg-info/dist-info data, which is what we read. The fact
>> that some people abuse requirements.txt and have it read in by their
>> setup.py is beside the point. Whatever the setup.py (thus
>> pip/easy_install/etc.) says it needs, the generator will dutifully
>> report.
>
>
> The fact remains in too many cases it will need to be manually adjusted, it
> won't be foolproof.
> Therefore I argue it would be better for it to be an opt-in so that new
> packagers don't immediately have to jump in into debugging a depgen they
> have no clue how really works.
We'll see how it will go. we have depgen for pkgconfig, libraries,
etc. for many years and people don't go and debug it immediately, but
for many of packages it will help a lot. Anyhow, we'll see after
couple of releases.
Neal suggested to have:
%__python_requires
%{_rpmconfigdir}/%{?pythondistdeps_enable:pythondistdeps.py}%{!?pythondistdeps_enable:pythondeps.sh}
--requires
in python.attr inside RPM.
I tested it and it just works once I specify `%global
pythondistdeps_enable 1` in spec. Can you help me to get this
included? With RPM part it's clear how to get this, but updating
guidelines and other stuff...
>
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
--
-Igor Gnatenko
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
[RFC] RPM's Python dependency generator
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) 2. Start enabling depgen and porting things (somehow reuse portingdb.xyz probably?) and submitting patches upstream 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 Neal, you can share how Mageia did that as well and feel free to comment this ;) Thoughts? -- -Igor Gnatenko ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: List of packages owning %{python3_sitelib}/__pycache__
On Tue, Nov 15, 2016 at 2:49 AM, Athos Ribeiro wrote:
> Hello,
Hi,
>
> Guidelines say that %{python3_sitelib}/__pycache__ should not be owned
> by python packages because python3-libs already owns it [1]. That
> directory is actually owned by system-python-libs.
>
> While going through a package review, I realized that 50+ packages own
> %{python3_sitelib}/__pycache__. To avoid generating noise to packagers,
> I am just listing those packages here [2].
Usually, people are just putting %{python3_sitelib/* which is wrong.
>
> [1] https://fedoraproject.org/wiki/Packaging:Python#Byte_compiling
>
> [2] - List of packages (rawhide) owning %{python3_sitelib}/__pycache__:
> cairo-dock-plug-ins
> netstat-monitor
> pydot
> pyparsing
> python-apipkg
> python-args
> python-autopep8
> python-bottle
> python-cma
> python-cmdln
> python-configobj
> python-configparser
> python-cookies
> python-cram
> python-cycler
> python-debian
> python-demjson
> python-dialog
> python-docopt
> python-empy
> python-entrypoints
> python-feedparser
> python-flask-assets
> python-flask-login
> python-flask-principal
> python-flask-whooshee
> python-flexmock
> python-fuse
> python-hwdata
> python-ipgetter
> python-jupyter-core
> python-markdown2
> python-mimeparse
> python-MultipartPostHandler2
> python-novaclient-os-networks
> python-novaclient-os-virtual-interfaces
> python-optcomplete
> python-pandocfilters
> python-path
> python-pefile
> python-pickleshare
> python-pika_pool
> python-plaintable
> python-polib
> python-pylcdsysinfo
> python-pyphen
> python-pytest-flakes
> python-pytest-pep8
> python-q
Fixed.
> python-random2
> python-responses
> python-scp
> python-setuptools_hg
> python-simplemediawiki
> root
> uwsgi
>
> --
> Athos Ribeiro
>
> http://www.ime.usp.br/~athoscr
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
--
-Igor Gnatenko
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: python-setuptools explicit build dependency
if setuptools is used, then you add BR: pythonX-setuptools. On Sat, Oct 29, 2016 at 10:31 AM, Germano Massullo wrote: > In spec files of Python based software, python-setuptools is a build > requirement that is mandatory for EPEL7, on Fedora instead it is not > required because it should already be a runtime dependency for python-devel. > By the way I remember I have heard that in next future it should be > added explicitly for various reasons. > Since I am actually doing some edits on the spec files of all Python > packages I mantain, I would like to know if what I have heard is true, > so that I can add it such dependency now. > > Thank you > > > ___ > python-devel mailing list -- python-devel@lists.fedoraproject.org > To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org > -- -Igor Gnatenko ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Question about Python applications / web applications
On Mon, Sep 12, 2016 at 4:32 PM, Germano Massullo wrote: > 2016-09-12 15:37 GMT+02:00 Igor Gnatenko : >> It depends on application/we-application. >> If it's not supposed to "import foo", then it's fine to build only one >> version. > > Does the following review request fall into that case? > python-django-netjsongraph - Reusable django app for collecting and > visualizing network topology > https://bugzilla.redhat.com/show_bug.cgi?id=1369213 Well, you package it -> you tell us if it fall into that case ;) If you don't know what you package probably it's better to not package it? > ___ > python-devel mailing list > python-devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org -- -Igor Gnatenko ___ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
Re: Question about Python applications / web applications
On Mon, Sep 12, 2016 at 3:06 PM, Germano Massullo wrote: > Hi, I have a question about Python applications and web applications. > I remember (but I am not 100% sure) that I have been told that if the > application / web application runs on Fedora, the packager will just > have to make the Python3 version and call it python-foo. No Python 2 > version has to be built. > > On the opposite site, for EPEL <= 7, Python 2 is the only choice. > > Am I right or not? It depends on application/we-application. If it's not supposed to "import foo", then it's fine to build only one version. > > Have a nice day > ___ > python-devel mailing list > python-devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org -- -Igor Gnatenko ___ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
Re: __pycache__ in python2 directory? O_o
Looks like this is bug in brp-python-compile, but I fixed python-Flask so it's not reproducible anymore ;) On Sun, Aug 21, 2016 at 8:31 AM, Nick Coghlan wrote: > On 21 August 2016 at 08:24, Zbigniew Jędrzejewski-Szmek > wrote: >> On Sat, Aug 20, 2016 at 05:17:59PM +0200, Igor Gnatenko wrote: >>> RPM build errors: >>> Installed (but unpackaged) file(s) found: >>>/usr/lib/python2.7/site-packages/__pycache__/site.cpython-35.pyc >>> >>> >>> This is from build of Flask. Looks really weird. >>> >>> Also it has some weird file inside: >>> /usr/lib/python3.5/site-packages/flask/testsuite/test_apps/lib/python2.5/site-packages/SiteEgg.egg >>> >>> Should we skip such things from RPM generator or we should remove that >>> or what? Thoughts? >> >> Looks like a in the build system or packaging script. >> Any automatic tools (like the RPM generator) should probably just ignore >> those, >> just like Python itself does. > > This looks like RPM is flagging a potential bug in the Flask spec file > to me - Python 3.x cache files shouldn't be showing up in the Python > 2.7 site-packages directory. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > ___ > python-devel mailing list > python-devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org -- -Igor Gnatenko ___ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
Re: .egg-link?
On Sun, Aug 21, 2016 at 8:28 AM, Nick Coghlan wrote: > On 21 August 2016 at 01:13, Igor Gnatenko wrote: >> $ cat /usr/lib/python3.5/site-packages/Flask.egg-link >> /builddir/build/BUILD/python3-python-flask-0.10.1-9.fc25 >> . >> >> I think we should exclude all egg-links from distribution.. > > +1 - if these show up, it's likely to be due to a call to "pip -e" or > "setup.py develop", and those kinds of operations shouldn't be used as > part of an RPM build. > >> Also >> question comes what we should do from RPM generator. >> Neal proposed for now to just skip it[0].. >> >> [0] https://github.com/rpm-software-management/rpm/pull/80 > > Is that the PR you intended to link? It doesn't seem to be related to > the problem of .egg-link files appearing in the RPM contents. It is. Think is that once you use pkg_resources.Distribution.from_location() on egg-link file it returns object, but obj.py_version returns None (though it shows warning that it can't read version from egg-link file). > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > ___ > python-devel mailing list > python-devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org -- -Igor Gnatenko ___ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
__pycache__ in python2 directory? O_o
RPM build errors: Installed (but unpackaged) file(s) found: /usr/lib/python2.7/site-packages/__pycache__/site.cpython-35.pyc This is from build of Flask. Looks really weird. Also it has some weird file inside: /usr/lib/python3.5/site-packages/flask/testsuite/test_apps/lib/python2.5/site-packages/SiteEgg.egg Should we skip such things from RPM generator or we should remove that or what? Thoughts? -- -Igor Gnatenko ___ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
.egg-link?
$ cat /usr/lib/python3.5/site-packages/Flask.egg-link /builddir/build/BUILD/python3-python-flask-0.10.1-9.fc25 . I think we should exclude all egg-links from distribution.. Also question comes what we should do from RPM generator. Neal proposed for now to just skip it[0].. [0] https://github.com/rpm-software-management/rpm/pull/80 -- -Igor Gnatenko ___ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
Re: Python 3.4 for Fedora 24+
On Thu, Aug 18, 2016 at 9:04 AM, Miro Hrončok wrote: > On 17.8.2016 19:04, Nick Coghlan wrote: >> >> On 16 August 2016 at 20:36, Miro Hrončok wrote: >>> >>> On 11.8.2016 11:26, Miro Hrončok wrote: >>>> >>>> >>>> Hi, >>>> >>>> As a follow up of our Flock discussion, I will build several Python >>>> versions in Copr, for development purposes (such as testing your code >>>> with tox on multiple Python versions). >>>> >>>> Those builds will be installable alongside regular python3/python >>>> packages and will be normal packages, no software collections etc. One >>>> flat package (i.e. no -libs, -devel...) with bundled setuptools and pip. >>>> >>>> First I've built Python 3.5 for Fedora 23, you can grab it here [1]. >>>> >>>> If you try to use tox with it, you'll have to use Python 3 version >>>> (python3-tox is the package and unfortunately also the command), due to >>>> a bug in virtualenv [2]. >>>> >>>> I would appreciate any feedback on the build, so I can build python34 >>>> package for Fedora 24+ in similar manner soon. >>>> >>>> Also python33 and python26 are planned. >>>> >>>> If those builds prove themselves useful I'll try to put them in Fedora >>>> (with a strict guideline that forbids any other package to depend on >>>> them). >>>> >>>> [1] https://copr.fedorainfracloud.org/coprs/g/python/python35/ >>>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1365941 >>> >>> >>> >>> You can now also test Python 3.4 for Fedora 24 and 25. >>> >>> https://copr.fedorainfracloud.org/coprs/g/python/python34/ >>> >>> There is one remaining issue, but it should not block you form using the >>> package. >>> >>> https://github.com/fedora-python/python34/issues/1 >>> >>> Let me know how it works for you. >> >> >> Nice! Would it make sense for us to have a "tox" section in the >> sidebar at >> https://developer.fedoraproject.org/tech/languages/python/python-installation.html >> that covers using these COPR builds with tox for cross-version >> testing? > > > It would. My long term plan here actually is to put this in Fedora proper > and make tox Recommend all the Pythons, so you could just dnf install tox > and it would bring all the runtimes (and you could prevent it if you didn't > want (actually I have no idea if we ahve some --without-recommends flag for > dnf, but anyway...)). dnf --setopt=install_weak_deps=false install tox > >> >> Cheers, >> Nick. >> > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > python-devel mailing list > python-devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org -- -Igor Gnatenko ___ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
Re: Update python-django EPEL7
It's against policies. Currently python-django has version 1.6. And 1.8 is major release. On Tue, Aug 16, 2016 at 6:17 PM, Germano Massullo wrote: > Hello, I would like to ask if it is possible to update python-django > for EPEL7 to, for example, 1.8 version. > I am actually going to fill a Review Request for > python-django-netjsongraph[1], and among its requirements, there is > python-django-rest-framework that cannot actually be packaged for > EPEL7 due python-django actual version > > Thank you > > [1]: https://github.com/interop-dev/django-netjsongraph > ___ > python-devel mailing list > python-devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org -- -Igor Gnatenko ___ 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
It can't track/change BR/R's as RPM is Turing complete and impossible to parse. Imagine, we have pythonXdist(foo) extracted from PyPI metadata, but in Fedora we still need to add some more BR for that, so we add it. When new release comes (still without added BR in upstream) rebase-helper will not be helpful. It can change only version of spec. On Mon, Aug 15, 2016 at 11:25 AM, Tomas Orsava wrote: > On 08/12/2016 05:40 PM, Petr Viktorin wrote: >> >> The idea with pyp2rpm is to work with the Python Packaging Authority so >> that the upstream metadata *can* be converted automatically. Ideally Fedora >> packagers would fix packaging problems upstream, rather than maintaining >> spec files. >> Ideas for a tool for *updating* spec files are also floating around. >> > There's already rebase-helper (it's an interactive tool as well as an > automatic one) that specializes in updating spec files. > > ___ > python-devel mailing list > python-devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org -- -Igor Gnatenko ___ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
Self-Introduction: Igor Gnatenko
Hi, I'm Igor and I'm working on Fedora as (mostly) packager for > 3 years. Currently I maintain ~ 60 python packages[0]. Currently I'm working at Red Hat in DNF team. Don't know what to say more. I'm already proven packager, but would like to join python SIG group and help. [0] $ curl --silent https://admin.fedoraproject.org/pkgdb/api/packager/package/ignatenkobrain/ | python3 -m json.tool | grep '"name": "python-' | wc -l 60 -- -Igor Gnatenko ___ python-devel mailing list python-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
