[blivet][master] Move the Blivet class into its own module

Vratislav Podzimek vpodzime at redhat.com
Mon Feb 16 08:23:23 UTC 2015


On Fri, 2015-02-13 at 12:03 -0500, Anne Mulhern wrote:
> 
> 
> 
> ----- Original Message -----
> > From: "Vratislav Podzimek" <vpodzime at redhat.com>
> > To: anaconda-patches at lists.fedorahosted.org
> > Sent: Friday, February 13, 2015 2:51:24 PM
> > Subject: [blivet][master] Move the Blivet class into its own module
> > 
> > See commit message for some explanation. But the most important thing is:
> > "See? No related anaconda change! The API is not changed by this patch."
> > 
> > That's possible thanks to the _LazyImportObject class which does quite a neat
> > trick to make sure we don't change the API while not importing everything the
> > Blivet class needs right away on any import from the blivet package.
> > 
> > Vratislav Podzimek (1):
> >   Move the Blivet class into its own module
> > 
> >  blivet/__init__.py                  | 1879
> >  +----------------------------------
> >  blivet/blivet.py                    | 1858
> >  ++++++++++++++++++++++++++++++++++
> >  tests/pylint/pylint-false-positives |    4 +-
> >  3 files changed, 1891 insertions(+), 1850 deletions(-)
> >  create mode 100644 blivet/blivet.py
> > 
> > --
> > 2.1.0
> > 
> > _______________________________________________
> > anaconda-patches mailing list
> > anaconda-patches at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
> > 
> 
> My comments are really all general.
> 
> At one point, not so long after I started, you stated that the ideal thing would be to move _all_ code out of blivet/__init__.py.
> This patch definitely doesn't do that. Is that because it no longer seems like a good idea to empty all code out of blivet/__init__.py, or is this patch just a good start, 2/3 of the way toward that eventual goal?
It's just another step on the way. The first one was the movement of the
autopart/osinstall code into separate modules, the second is this.

> 
> I'm also dubious about the _LazyImportObject proxy class. If we just break the API, which we've done before and will probaby do again, we can save ourselves the ingenuity of this special class. What is the compelling reason for not breaking the API which makes this solution seem desirable?
With the release 1.0 we should finally get to keeping a stable API. So
not breaking API is quite a good reason for 15 lines of extra code. The
other is a just aesthetical and maybe even personal, but I really don't
like 'from blivet.blivet import Blivet'.

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic



More information about the anaconda-patches mailing list