sourcecred / sourcecred-python

Python implementation of the SourceCred algorithm (under development)

SourceCred Python

This will be a Python implementation of the sourcecred algorithm, intended to better inspire and include data scientists and those familiar with the Python programming language.

under development

Development

My development strategy is to mirror sourcecred to the largest extent possible. As a developer, if there is a change in (what I consider the upstream language) I would want it to be seamless to identify the "same" file here and make the change.

Testing

To start, we will just have linting. Testing will be the largest driver of "does this work as we expect" so akin to the overall development strategy, I want to try and use the "same" tests to validate we are okay.

Pull Requests

I'll put some skeleton files here, and largely work on the @vsoch fork on the add/sourcecred-core. This way, I can open a pull request proper to get feedback (and trigger tests, etc.), and I won't bother folks with notifications here for activity that I do.

sourcecred-python's Issues

[DRAFT] Early points for discussion

This is a list of TODOs / discussion points that I don't want to forget :)

• LICENSE I copied the sourcecred standard - using MIT and APACHE, and I'd want to talk about if/when SourceCred is an official entity (we could use on licenses) and update here.
• Pypi metadata: We can put various classifications for everything from intended audience to license and programming languages / platforms supported. I chose the standard that I would expect, and I'd want to ask for feedback.
• Typing: I've been hesitant to add native typing to most of my Python projects, because realistically most of the world isn't there yet (and we would lose a lot of users to require 3.8+) however as an intermediate we could use mypy. I won't add this off to bat, but it could be added after. I'm starting to see in the compat.js that we really should be checking types. Ohhh Python :)
• Others to add to pypi: I can manage the package (I manage quite a few!) but I'd want to add any others that would want / warrant access to it. Pypi has recently been upping their security game (two factor auth and tokens, just a random note)
• Testing: I figure it's easiest to start with GitHub Actions, since it's a native thing now. If there are other builds warranted (e.g., containers) then we can consider adding another platform to speed things up.
• Containers: speaking of! If it's appropriate, we could provide a container with SourceCred python. As long as we are able to keep this relatively up to date, this seems like it would be useful for some kind of data scientist that quickly wants to grab the latest version for a project.
• Any convention preferred for file headers (e.g., see this post) I'm doing a standard module docstring that references the licenses provided with the repository, and any small details that I see in the upstream language sourcecred/sourcecred.
• I can use camel casing to mirror the upstream project, is that weird?
• add proper logger / warnings
  Please consider this issue under development / draft - I will remove this statement when it's ready for discussion! I have a ton of work to do before that, and I also will be adding a lot more points, and likely even moving them into their own issues. This is an initial brain dump.

[post-draft] look for opportunites to use multiprocessing

[post-draft] plugins need to be separated

The plugins are totally tangled and hard coded in the code design - there should be a default set that are installed, but they should not be required / should be customizable. It doesn't make sense to refactor this before anything is finished being ported, but needs to be kept in mind.