Skip to content

Split code up into multiple modules #49

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

Open
nat-n opened this issue May 21, 2020 · 2 comments
Open

Split code up into multiple modules #49

nat-n opened this issue May 21, 2020 · 2 comments
Assignees
Labels
enhancement New feature or request high priority medium Medium effort issue, can fit in a single PR

Comments

@nat-n
Copy link
Collaborator

nat-n commented May 21, 2020

Currently both the plugin and runtime library as single modules. Maybe there's an element of personal preference here but I think splitting them up into more single purpose modules (and possibly sub-packages) would make the code easier to understand and work with.

It would also add some flexibility for optimisations such as only importing the parts that are required, e.g. excluding client/server code if not needed.

I'd be happy to work on splitting these modules up if there are no objections (maybe at a time when there are fewer open PRs). @danielgtaylor

@nat-n nat-n self-assigned this May 21, 2020
@nat-n nat-n added enhancement New feature or request question Further information is requested labels May 21, 2020
@boukeversteegh boukeversteegh added this to the Better Imports milestone May 25, 2020
@boukeversteegh boukeversteegh added large Large effort issue, multiple PRs, needs to be split up medium Medium effort issue, can fit in a single PR and removed question Further information is requested large Large effort issue, multiple PRs, needs to be split up labels May 25, 2020
@boukeversteegh
Copy link
Collaborator

hey @nat-n 😃

In attempt to get a better overview of the internal dependencies of objects inside __init__.py, I have organized the objects into functional and logical groups, and identified the dependencies between those groups.

If you'd like to split up the init-file as part of this issue, the following overview will probably come in handy.

  • base - Base-classes for compiled output, public (depends on runtime, proto3)

    • Message
    • Enum
    • FieldMetadata
    • ServiceStub
    • T dataclass_field _PLACEHOLDER PLACEHOLDER ProtoClassMetadata
  • util - part of public api (depends on base)

    • Casing
    • serialized_on_wire
    • which_one_of
  • proto3 - specs of proto3 format (no dependencies)

    • FIXED_TYPES INT_64_TYPES PACKED_TYPES
    • TYPE_BOOL TYPE_BYTES TYPE_DOUBLE TYPE_ENUM TYPE_FIXED32 TYPE_FIXED64 TYPE_FLOAT TYPE_INT32 TYPE_INT64 TYPE_MAP TYPE_MESSAGE TYPE_SFIXED32 TYPE_SFIXED64 TYPE_SINT32 TYPE_SINT64 TYPE_STRING TYPE_UINT32 TYPE_UINT64
    • WIRE_FIXED_32 WIRE_FIXED_32_TYPES WIRE_FIXED_64 WIRE_FIXED_64_TYPES WIRE_LEN_DELIM WIRE_LEN_DELIM_TYPES WIRE_VARINT WIRE_VARINT_TYPES
  • runtime/ - everything not needed for compiling

    • fields - helper methods used by base to define message fields
      • bool_field bytes_field double_field enum_field fixed32_field fixed64_field float_field int32_field int64_field map_field message_field sfixed32_field sfixed64_field sint32_field sint64_field string_field uint32_field uint64_field
    • internal - other internal objects (depends on proto3)
      • _Duration
      • _get_wrapper
      • _MetadataLike
      • _pack_fmt
      • _preprocess_single
      • _serialize_single
      • _Timestamp
      • _Value
      • encode_varint
    • io - for reading/writing message (no dependencies)
      • datetime_default_gen
      • DATETIME_ZERO
      • decode_varint
      • parse_fields
      • ParsedField

@nat-n
Copy link
Collaborator Author

nat-n commented May 30, 2020

@boukeversteegh Good summary, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request high priority medium Medium effort issue, can fit in a single PR
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants