Customize how packages are added to views#7152
Conversation
…icting __init__ files for packages in the same namespace (still need to update remove_from_view)
…kage in a namespace
…re the root is the extendee installation prefix
…vation tests are still failing)
…s passing with new refactor
… are only ever managed for views now). add special-case code for extensions layout to detect if it is managing extensions within a package prefix (i.e. global extensions from before)
…mplicates the tests but removes boilerplate code from subclass implementations
…alled add_files_to_view) for Package and subclasses
…nt) to rewrite shebang line for scripts when they are added to views
…) dont attempt to link a file when the destination already exists (if this is a problem, then view_file_conflicts should have complained)
… into new api changes
…r deactivate --all
…or extension management in global activations
|
@tgamblin the following updates have been made to address the review:
|
|
Arg never mind not ready yet: http://spack.readthedocs.io/en/latest/packaging_guide.html#activation-deactivation is in fact out of date WRT this. |
…osing packages and (b) mention view override functions
…e subdirectory check in Python package to use this function
…workflows section
|
@tgamblin in addition to #7152 (comment), the documentation is now updated and generally attempts to emphasize views over global activations. EDIT: there are also a couple of functions added to the |
tgamblin
left a comment
tgamblin
left a comment
There was a problem hiding this comment.
@scheibelp: this looks great to me!
I think a follow up PR can reduce the complexity of overriding the various methods in PackageViewMixin. We should look at how packages are using those methods and try to make the specification of special files more declarative, but this is good for now.
The docs look great, as well.
|
Is this |
|
It's just saying we shouldn't consider an |
|
They are not empty, also don't have the exact same contents :( I read it's required for Python <= 3.2. In Python 3.3+ you can just delete the file post install, and Python should locate things in the namespace. |
|
We do still care about the 2.7 stack in Spack... so I think we do care about it. |
5 participants
Functional updates:
pythonnow creates a copy of thepythonbinaries when it is added to a viewPythonPackage) rewrite their shebang lines to refer to python in the view...lib/site-packages/namespace-example/__init__.py__init__files will also remain when removing any package in the namespace until the last package in the namespace is removedGenerally (Updated 2/16):
add_files_to_viewto customize how it is added to a view (and at the moment custom definitions are included forpythonandPythonPackage)remove_files_from_viewto customize which files are removed (e.g. you don't always want to remove the namespace__init__)view_file_conflictsto customize what it considers a merge conflictPackage.activateis more straightforward (seePython.activate)add_files_to_viewmethod (seePythonPackage)LinkTreeis refactored to have separate methods for copying a directory structure and for copying files (since it was found that generally packages may want to alter how files are copied but still wanted to copy directories in the same way)TODOs (updated 2/20):
LinkTreemethods: currently there is a separate set of methods for replicating just the directory structure without the files, and a set for replicating everythingview.add_extension, but global activations do not to avoid some extra work that goes into maintaining external views. I'm not sure if addressing that needs to be done here but I'd like to clarify it in the comments (UPDATE: for now I have added a TODO and in my opinion this can be merged now and the refactor handled later)Package.activate) are out of date and reference a distinction between global activations and views, they need to be updated