Something Joe Brockmeier mentioned in his Fedora Marketing talk at
Flock last week was the need for development teams to be active in
providing content for the release announcements.
With the Fedora 23 Alpha coming out last week, I looked at the Release
Notes to see if there was anything about the "Python 3 as default"
change, but didn't see anything.
Was there something there and I just missed it, or does something need
to be written up and passed to the folks responsible for creating the
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
While figuring out how to proceed with development of
pyp2rpm I've realized that I have no idea how to properly
package docs generated by sphinx for python module having
both python2 and python3 subpackages, I've decided to go
with the following pattern:
If package foo has docs generated with sphinx:
- add BuildRequires: python-sphinx
- use sphinx (unversioned binary) to generate docs
- package docs under python-foo-docs subpackage
Apply same behavior for every module, even if module
ships both Python2 and Python3 subpackage its docs will be
generated only once and stored under python-foo-docs.
(Assuming that docs are same for both python major versions.)
What do you think?
Just thought I'd let this list know python-scandir is now in the stable
repos. The code itself has been accepted as an enhancement to the os module
in Python 3.5, but the original independent module is great for older
versions. I tend to use as an optional speedup when I am heavily using
os.walk() or os.listdir(). The maintainer has been very responsive.
I am one of the lead upstream developers of matplotlib. We are in the
process gearing up for two major releases in the next few months.
First we will be doing a 1.5 release which will be a new feature release
and has a new external dependancy (https://github.com/matplotlib/cycler)
which will need to be packaged. There is a version of cycler on pip and I
plan to do a 1.0 release of cycler around/before the mpl1.5 release.
Right after that we will be doing a 2.0 release that will have no new
features, but will be changing many of the visual defaults.
Is there anything we can do upstream to make your lives easier on the
As many of you may be aware, FPC has been fielding several tickets
surrounding python packaging lately, and the last one was a sizable
reorganization that unfortunately was based on an older version of the
guidelines. While merging it all together I just said screw it and just
cleaned up the page like I've always wanted to do.
I suggest anyone who hasn't lost sanity due to this whole guidelines
revision process pile onto:
Here's the contents of that comment to save you a click.
OK, this was a lot of stuff, and the more I worked on it, the more
annoyed I became. Plus the wiki kept eating my edits and I kept getting
lost in the overhuge page. So, I've probably gone too far in cleaning
up but I'll present what I have and if people yell at me then I'll try
something less ambitious.
There are now three pages:
The first page incorporates the following changes:
* Notes that these guidelines apply only to F22+ and EPEL7. Points at
the 2nd page for old guidelines.
* Includes the information about not retiring python-version-specific
subpackages in stable releases.
* Makes BuildRequires: section much more succinct.
* Makes sure python2-foo provide is versioned, mentions
* Makes the macro table collapsible and collapsed by default.
* Remove EL6-specific cruft (it's in the old guidelines page).
* Move the parts of the byte compilation section that nobody ever uses
off to the Appendix page.
* Make the single-rpm single-dir case the default. Move the
entire multiple-dir case to the appendix.
* Completely remove %with_python3 from the example spec. We want people
to build for python3. People just paste this in without knowing why
they would ever need it. If you're using the new macros you can't
just conditionalize for EL6 anyway. This really makes the spec look
nice. Macro-izing the summary and description would make it look even
nicer once the description gets longer than a line.
* Uses a generic "example" module as an example. Two different approved
proposals changed it to two different things; I just punted.
* Puts the example spec all together without a bunch of text and admons
and whatnot in the middle.
* Moves the 2to3 section to the appendix.
* Simply refers to the eggs section. That whole part at the bottom was
quite awkward and I don't think most people even looked down that far.
* Loads and loads of typo fixes, grammar fixes, and cleanups.
The current main guideline page is now a bit over half the length it was
and on the page it's less because of the collapsed macro table. I find
it to be far more readable, and the sample spec no longer turns my
The old guidelines page is just as it was before writing up the new
macros, except that I added a short explanatory section at the top.
The appendix page conveniently holds things which we probably should
document but pretty much nobody would actually want to read without some
Functionally I do not believe I have gone beyond anything upon which we
voted but I wanted to toss this out there and see if anyone yells before
I copy it into place. Been trying to get this done for three days now
and I think I'm finally there.