"Smith, Barry F." <[email protected]> writes: > If we stash the --download-xxx=yyy yyy value and the state of the xxx.py > then we can know that the package may be need to be re-downloaded, > re-configured, rebuilt, reinstalled. Essentially get the dependencies of > package xxx on itself right. There is also the dependency of package xxx on > packager www (for example hdf5 changes thus pnetcdf needs to be rebuilt. > Finally there is the dependency of xxx on other stuff that may change in > config (for example package.py) > > My branch handles all these dependencies (at the cost of rebuilding > more than what may need to be rebuilt)
I think the cost of manually rerunning configure repeatedly to notice dependencies, delete pkg.conf files, etc. (and the associated cognitive load) is *much* worse than rebuilding a bit more than strictly necessary. We've been paying for --download being a quick-n-dirty hack. If it's going to be a package manager, it should accurately track dependencies and dependent versions. > but it is a different model then how we have traditionally used > --download-xxx. It is not clear to me if we should just discard the > old model for a new one, support them both or something else. It seems > inefficient to support both models forever, maybe a smarter hybrid of > the two is desirable. I need to develop some experience with my new > model to see how it can be improved, extended or if it is complete > trash. I am not sure trying to "patch up" the old model is the best > approach; though maybe it is. > > Barry > > >> On Jun 28, 2019, at 10:41 AM, Jed Brown via petsc-dev >> <[email protected]> wrote: >> >> If we configure with --download-pnetcdf (version 1.9.0), then update the >> PETSc repository to use a new version (1.11.2), then re-run ./configure >> --download-pnetcdf, we get a warning making us look like dolts: >> >> =============================================================================== >> >> >> Warning: Using version 1.9.0 of package pnetcdf; PETSc is tested with >> 1.11 >> >> Suggest using --download-pnetcdf for a compatible pnetcdf >> >> >> =============================================================================== >> >> It looks like we have a mechanism for gitcommit versions, but not for >> normal numbered versions? >> >> NB: There are other changes in updating pnetcdf that will bypass this >> issue today, but I wanted to raise it in case someone had a vision for >> how the logic should be organized. It's currently spread out, and >> any attempt at a fresh download is skipped if there is a matching >> download directory: >> >> if not self.packageDir: self.packageDir = self.downLoad()
