Skip to content

Packaging #2

@jpmorgan98

Description

@jpmorgan98

When packaging an open source app there are a few things we need to configure. I am working on this on my fork and have made a draft PR so we can collaborate. I know this is alot but these are all of the things that are best practices, none are required. This will also go along way in getting other folks to be able to make contributions and install seamlessly eventually getting harmonize into a polished piece of deploy-able software! MC/DC implements most of this so for examples, go there. I will add links over the next lil bit

Please feel free to make alterations as you see fit. I will go thru and add links and resources to all these notes in the coming days but I am really excited to be on this dev team and make a contribution to harmonize!

Directory structure

Python functions usually have the structure of
Harmonize/harmonize/paython_package.py
I have done this but not yet edited the tests and examples

Initialization Functions

Here we need to define all the functions a user needs to be aware of. From my cursory look at MC/DC its harmonize.RuntimeSpec. But add any I missed.

MISC Config Files

I have made most of the ones I think are per tenant

  • README.md: description of install, citation, contribution, etc. Think of this as the first documentation broad strokes you want people to know about.
  • pyproject.toml: required for packing where we list all the dependencies
  • CITATION.cff: for auto archiving at version release
  • CODEofCONDUCT: Describing a contribution code of conduct. I put the same one MC/DC uses in there

Other things we should probs do at some point but are by no means urgent

  • Testing: weather in C++ or Python that can be run via command line request. I can provide more examples of how this is done.
  • CI: once we get testing figured out then we can start to do CPU only tests in github actions and configure CI for LLNL GPU stuff which I think I might know how to do.
  • Auto packaging: I can set this up pretty easy once we decide how to do the res
  • Documentation: in the read me is fine for now but we can start building a ReadTheDocs like MC/DC's

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions