On Wed, Aug 14, 2013 at 11:36 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > I spent last weekend at "Flock to Fedora", mostly due to my day job > working on the Beaker integration testing system > (http://beaker-project.org) for Red Hat, but also to talk to folks > about Fedora and Python interactions. > > A completely unexpected discovery over the weekend, was that some of > the RPM folks are exploring the idea of switching the *user* facing > format for the packaging system away from spec files and towards > directly executable Python code. Thus, you'd get away from the painful > mess that is RPM conditionals and macros and have a real programming > language to define what your built packages *should* look like, while > still *producing* static metadata for consumption by installers and > other software distribution tools. > > Hmm, does that approach sound familiar to anyone? :) > > Anyway, we were talking about how they're considering approaching the > install hook problem, and their approach gave me an idea for a better > solution in PEP 426. > > Currently, PEP 426 allows a distribution to define "install hooks": > hooks that will execute after the distribution is installed and before > it is uninstalled. > > I'm now planning to change that to allowing distributions to define > "export hooks", based on the cleaned up notion of "export groups" in > the latest version of PEP 426. An export hook definition consists of > the following fields: > > * group - name of the export group to hook > * preupdate - export to call prior to installing/updating/removing a > distribution that exports this export group > * postupdate - export to call after installing/updating/removing a > distribution that exports this export group > * refresh - export to call to resynchronise any caches with the system > state. This will be invoked for every distribution on the system that > exports this export group any time the distribution defining the > export hook is itself installed or upgraded > > If a distribution exports groups that it also defines hooks for, it > will exhibit the following behaviours: > > Fresh install: > * preupdate NOT called (hook not yet registered) > * postupdate called > * refresh called > > Upgrade: > * preupdate called (old version) > * postupdate called (new version) > * refresh called (new version) > > Complete removal: > * preupdate called > * postupdate NOT called (hook no longer registered) > * refresh NOT called (hook no longer registered) > > This behaviour follows naturally from *not* special casing > self-exports: prior to installation, the export hooks won't be > registered, so they won't be called, and the same applies following > complete removal. > > The hooks would have the following signatures: > > def preupdate(current_meta, next_meta): > # current_meta==None indicates fresh install > # next_meta==None indicates complete removal > > def postupdate(previous_meta, current_meta): > # previous_meta==None indicates fresh install > # current_meta==None indicates complete removal > > def refresh(current_meta): > # Used to ensure any caches are consistent with system state > # Allows handling of previously installed distributions >
I think I'm okay with this so long as it remains optional. I'm not crazy about executable build specs where they're not necessary. For most cases, especially in pure Python packages, it's frequently overkill and asking for trouble. So I would still want to see a well-accepted static build spec for Python packages too (sort of a la setup.cfg as parsed by d2to1, only better), though I realize that's a separate issue from PEP 426. Erik _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
