Re: Tox automation in packaging macros

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2020-02-28 at 20:42 +0100, Miro Hrončok wrote:
> 
> > * ...the Shiny New Stuff does not appear to be available on EPEL *at
> > all* yet - not even EPEL 8. This makes it a bit of a non-starter if you
> > want to use the same spec file bits across Fedora and EPEL. I realize
> > it may be impractical/impossible to backport everything to EPEL 7, and
> > am getting close to the point where I throw in the towel and drop
> > Python 2 support from my projects' master branches and hang the EPEL 7
> > package repos out on a branch, but EPEL 8 would be nice and ought to be
> > possible?
> 
> This stands in a way of having this in EPEL 8, AFAIK:
> 
>   - no automatic RPM buildrequires
>   - ancient pip (PEP 517 support was added in 19.0, we have 9.0.3)
>   - ancient setuptools (40.8 is needed, we have 39.2.0)
>   - no tox (but it's being packaged for EPEL8 as we speak)

Yeep! I didn't realize we had such ancient bits in 8...

> How are we supposed to do progress in Fedora when people dislike it when it is 
> not included in EPEL?

I assume there's an extra "not" here. On that assumption - I understand
the problem, but if you check the history of my builds in EPEL, I'm
definitely not in that group of people :P

> > * Unless I'm missing something, what you suggested for tox - "ideally
> > we should convince upstreams to only run tests with default toxenv" -
> > actually seems weirdly difficult to implement. AFAIK none of the
> > official or unofficial tox docs I can find really cover the idea of
> > having an environment that's *defined* but is not *default*. It seems
> > to be virtually universal practice with tox that you put every
> > environment in `envlist`...and if you just run `tox` without any `-e`
> > argument or special env var, it runs every environment in `envlist`.
> > People seem to assume all environments will be default, and if you want
> > to run fewer than 'all of them' you filter with `-e` or whatever.
> 
> What I meant with "ideally we should convince upstreams to only run tests with 
> default toxenv, not linters" was this:
> 
>   `tox -e py37` should only run tests
>   `tox -e py38` should only run tests
>   `tox -e py39` should only run tests
> 
> Linters should run in `tox -e lint`, or `tox -e py38-lint`.
> 
> %tox runs `tox -e py3X` by default.

Ah, so essentially the scheme I suggested, but by 'default toxenv' you
meant the default env *of %tox*, not the default for just calling
`tox`?

> > So in the end I gave up and wound up just making the `-ci` environments
> > the defaults, explicitly declared in envlist, and figuring I'd have the
> > spec file use `-e` to explicitly run the non-ci environments.
> 
> That's what %tox does.

yeah, I figured that one out later :)

> Sorry but I cannot help you have nice new things if you decide to have old 
> things. You need to choose - backwards compatibility or new features.

See above, I know which one I choose :P
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux