> On Feb 25, 2018, at 10:07 PM, Jed Brown <[email protected]> wrote: > > "Smith, Barry F." <[email protected]> writes: > >>> On Feb 25, 2018, at 9:57 PM, Jed Brown <[email protected]> wrote: >>> >>> "Smith, Barry F." <[email protected]> writes: >>> >>>>> On Feb 25, 2018, at 9:46 PM, Jed Brown <[email protected]> wrote: >>>>> >>>>> Satish Balay <[email protected]> writes: >>>>> >>>>>> On Sun, 25 Feb 2018, Lawrence Mitchell wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>>> On 25 Feb 2018, at 21:13, Jed Brown <[email protected]> wrote: >>>>>>>> >>>>>>>> >>>>>>>> The try part of that commit (around os.remove) is necessary. Also, >>>>>>>> "rmdir -p" provides a useful semantic in this context, but needs to be >>>>>>>> implemented manually in Python (or I don't know where that >>>>>>>> functionality >>>>>>>> is available in the standard library). >>>>>>> >>>>>>> shutil.rmtree >>>>>> >>>>>> I think [in uninstall script] - we want to delete dirs only if the dir >>>>>> is empty. [if not empty - it could contain files installed by a >>>>>> different package - as its common to install multiple packages in the >>>>>> same prefix] >>>>> >>>>> Yeah, "rm -r" is much different from "rmdir -p". >>>>> >>>>>> Also - thinking about it - its not clear if we can really do a proper >>>>>> uninstall - esp with --download-packages. >>>>>> >>>>>> Previously - 'make install' would also install the downloaded packages >>>>>> and we kept track of them for the uninstall script. But now - we let >>>>>> each package do its own 'make install' to the prefix location. But we >>>>>> don't have an 'uninstall' option for these externalpackages. [I don't >>>>>> know if any of them provide 'make uninstall' feature] >>>>> >>>>> PETSc --download-* is a package manager, albeit very crufty (though it >>>>> gets the job done). Basically all package managers function by >>>>> installing with a private DESTDIR, bundling up the result, then >>>>> unpacking into the target. >>>> >>>> That's not how PETSc's works. It tells the each package the final prefix >>>> and each package installs into that location directly. >>> >>> That's just because PETSc's package manager is kinda crappy because >>> nobody wants to admit that it really is a package manager. If uninstall >>> is to be a thing at all, then it's definitely the way to go. >> >> We use to do it the "package manager way" but I think so many packages >> couldn't be DESTDIRed and then installed that we went with the install >> directly approach. > > Many/all of those packages are available in Debian or Conda or Homebrew, etc. > >> I think it is wrong to call PETSc's thing a package manager. It is and >> always has been only a package installer, it is hopeless at managing >> packages. > > And yet we're talking about uninstall and we also have support for > upgrading them (except that it doesn't clean up the old version and thus > isn't very reliable).
Huh, it has support for upgrading them? > It's a package manager despite conspicuous > missing features.
