Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

move amendments and imports under project_modifiers #344

Closed
stolarczyk opened this issue Apr 8, 2020 · 6 comments
Closed

move amendments and imports under project_modifiers #344

stolarczyk opened this issue Apr 8, 2020 · 6 comments
Assignees

Comments

@stolarczyk
Copy link
Member

amendments and imports to fall under project_modifiers ?

the it'd be:

project_modifiers:
  amend: ...
  imply: ...
  import: ...
sample_modifiers:
  append: ...
  imply: ...
  derive: ...
  ...

Originally posted by @nsheff in #342 (comment)

@stolarczyk stolarczyk self-assigned this Apr 8, 2020
@nsheff
Copy link
Contributor

nsheff commented Apr 8, 2020

Arguments for:

  • parallel structure with sample_modifiers
  • more clear that amendments and imports modify the project
  • we would be better prepared for future modifier types, such as proposed in implement project_modifiers.imply #342

Arguments against:

  • adds another hierarchical layer for imports/amendments
  • imports somehow feels like it belongs at the top level... (just a familiarity thing?)
  • amendments are different than all other modifiers in that they don't run automatically (but I suppose each modifier has its own idiosyncrasies)

Overall I think it makes sense to use project_modifiers as proposed. I view the parallel structure as a substantial benefit, and the semantic clarity of what amend and import does also. I would like to hear any feedback from @johanneskoester, @jpsmith5, @afrendeiro, @vreuter if you care to chime in.

@afrendeiro
Copy link
Contributor

Slight preference for the more hierarchical project_modifiers.

@vreuter
Copy link
Member

vreuter commented Apr 13, 2020

So currently those exist as project-level keys, right? And functionally, "amendments" is basically like what was "subprojects?"

@vreuter
Copy link
Member

vreuter commented Apr 13, 2020

So currently those exist as project-level keys, right? And functionally, "amendments" is basically like what was "subprojects?"

If that understanding is roughly true, I agree w/ @afrendeiro . My preference isn't strong either, but I like the parallel structure that's gained by making it hierarchical rather than a "level up," and I think it fits nicely w/ the Python tenet of explicit-over-implicit.

@stolarczyk
Copy link
Member Author

So currently those exist as project-level keys, right?

yes

And functionally, "amendments" is basically like what was "subprojects?"

Yes, except for the fact that you can activate multiple at once

@vreuter
Copy link
Member

vreuter commented Apr 13, 2020

Yes, except for the fact that you can activate multiple at once

Nice! 🔥

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants