Re: Matplotlib 3.10.0 for trixie?
On 12 April 2025 6:18:20 pm IST, James Addison <jay@jp-hosting.net> wrote:
>Hi Nilesh, Alex,
>
>Responding to the first point only, at the moment:
>
>On Sat, 12 Apr 2025 at 07:39, Nilesh Patra <nilesh@debian.org> wrote:
>> [ ... snip ... ]
>> 1. matplotlib has historically shipped /etc/matploblibrc to force tkagg and patched the code
>> to use this if there are no user defined rc files see [1]. However, this was not
>> handled properly via maintscripts so that'd mean over-writing user-modified /etc/matplotlibrc.
>
>Ah; what is the problem related to the maintscripts?
>
>The /etc/matplotlibrc file is considered a config file by apt/dpkg (it
>is not removed unless a purge is requested), so I was hoping that
>shipping a default/unmodified matplotlibrc in an updated 3.10 upload
>(as Alex suggests in his thread) would provide a useful additional
>conflict-resolution step for anyone who has modified theirs.
I usually had to mention such files it in d/conffiles.
I now tried to unpack control.tar.xz of python3-matplotlib-data and saw it there regardless.
Seems dh is doing its magic so I suppose my concern quoted above is invalid.
Regardless, it makes sense to still do a -3 upload.
>> The backend detection logic is now better and I feel we should get rid of the "yield '/etc/matplotlibrc'" in
>> [1] and also stop shipping the conffile both and add in a rm_conffile to remove previously
>> installed /etc/matplotlibrc.
>
>I don't have a strong opinion about this part, although when in
>sysadmin mode, I do tend to go looking in /etc first to find config
>files.
>
>On the other hand, we wouldn't be the first package to read config
>files from elsewhere on the filesystem - pipewire springs to mind as
>another case where default config files are located under /usr/share,
>for example.
Right. But, pipewire is much more than a python library that is intended to be consumed by other python applications and/or end user as a part of their code.
It makes sense to have binaries, command line utilities even gui apps to have a conffile in /etc. But it looks weird for a python library to have one especially when the practical benefits are not great.
I really doubt if any sysadmin takes the time to edit /etc/matplotlibrc. But yes this should be targeting forky release instead.
>> Probably also a d/NEWS to inform the sysadmin that this no longer works. It does not make
>> sense to me for a python lib to have a conffile.
>
>+1 to a NEWS entry. I'm not so sure about removing the conffile
>entirely yet, though. I think it may be safer to treat it as a
>feature deprecation, allowing time for feedback about any use cases
>that seem to require it and/or for users to migrate to alternatives.
ACK.
>Regards,
>James
Best,
Nilesh
Reply to: