Code organisation can be improved

[dhruvkb]

Description

Currently the code in the repository is organised in directories on the basis of the GitHub Actions workflow they enable, each with its own Python environment and each independent of the other. This however does not take into account that multiple workflows may share code, utility functions and constants with each other.

For example in #58, a number of constants and functions were duplicated from push_data_to_ccos/ to sync_community_team/ because the way the repos are organised prohibits sharing. I believe the code can be better organised to be more DRY, all the while maintaining a reasonable amount of separation between the different workflows.

Reproduction

1. Write a new workflow
2. Observe inability to reuse existing code
3. Feel dread as you copy code, verbatim, from one folder to another.

Expectation

Even when concerns are separated, constants and common functions like setting up a client to GitHub or Asana should be placed in a central location and shared.

Resolution

• I would be interested in resolving this bug.

[tushar912]

@dhruvkb i would like to work on this

[tushar912]

I am thinking of implementing it as follows . set_up_github_clientand get_cc_organization are used in a lot of files so i would create a common file utils which can be used for all the workflows .It would also contain constants like GITHUB_ORGANIZATION and GITHUB_TOKEN. Also in push_data_to_ccos Setting up asana could be placed at a single place. @dhruvkb Please tell if I am missing anything.

[dhruvkb]

@tushar912 the idea of containing duplicated code in a single location is a good idea. But putting the file in a different folder might present some complications in terms of how Python resolves packages so you should check how that works.

[tushar912]

Yes

[avats-dev]

@tushar912 the idea of containing duplicated code in a single location is a good idea. But putting the file in a different folder might present some complications in terms of how Python resolves packages so you should check how that works.

yeah, relative imports could be a trouble! I tried them while fixing logging. @tushar912 if you get to know a better way, ping me back as I also need to implement this for improved logging. Thanks 👍

concerned with #63

[tushar912]

I think here we can use sys.path.append to add the path of folder to sys.pathand then we can easily import files by their name rather than using relative imports.

[avats-dev]

@tushar912 yes we can use sys.path but that might be a dangerous step as it changes the system path and may abrupt the script's working. That's why I haven't used it yet, and thought about relative imports. Let's see what @aldenstpage has to say.

[TimidRobot]

Fixed by #143