executablebooks / meta

A community dedicated to supporting tools for technical and scientific communication and interactive computing
https://executablebooks.org
129 stars 164 forks source link

Proposal: Move markdown-it-py out of EBP #841

Open chrisjsewell opened 1 year ago

chrisjsewell commented 1 year ago

Similar to markdown-it (the JS implementation) markdown-it-py and related packages such a as mdit-py-plugins and mdformat have a different maintainer and user base to other packages in the EBP organisation (which are primarily focussed on serving jupyter-book or mystjs). Therefore, it would serve them best to sit in their own dedicated GitHub organisation

chrisjsewell commented 1 year ago

See also #840, with applying to be a Jupyter sub-project, I also think it will be beneficial to reduce the number/scope of packages that EBP is specifically responsible for.

chrisjsewell commented 1 year ago

Just to put a clear timeline on this, unless there are objections within the next two weeks, I will commence moving markdown-it-py out of executablebooks.

cc @choldgraf

chrisjsewell commented 1 year ago

This has now been outstanding for many months, @executablebooks/steering-council please could you advise on moving forward with this thanks?

choldgraf commented 1 year ago

I think there have just been many other things that folks are attending to. Is there a reason that you think a decision needs to be made on this quickly? I agree we should decide about the breakdown of repositories before a formal proposal is made to migrate into the jupyter/ org, but I don't think this is a critical issue currently.

For the points you made above, I think they both make sense to me. I agree that markdown-it-py has a different userbase and that there is upside to reducing the scope of maintenance that the executablebooks project must oversee.

The biggest downside I see is that markdown-it-py is a critical part of the Python stack in MyST, and so giving up the governance of markdown-it-py might have downsides in the long-term (e.g. if the executablebooks/ org depends critically on markdown-it-py changes being needed, but does not have the authority to make them on its own).

How realistic do you think that scenario is? Have we had many instances in the EBP where we needed changes in markdown-it-py quickly in order to fix bugs / make releases / etc in the MyST Python ecosystem? If so, perhaps we should define a level of "stability" that markdown-it-py reaches before spinning it off into a standalone project?

chrisjsewell commented 1 year ago

Is there a reason that you think a decision needs to be made on this quickly?

This proposal, in one form or another, essentially has been outstanding for at least a year. Especially with your coming "departure" (#873) I feel then this decision will then probably never come to fruition?

The biggest downside I see is that markdown-it-py is a critical part of the Python stack in MyST

As mentioned above, mystjs already depends on markdown-it, which is outside this organisation and, similarly, the jupyter organisation relies on marked and mistune for Markdown parsing, also outside their organisation. This is no different.

e.g. if the executablebooks/ org depends critically on markdown-it-py changes being needed, but does not have the authority to make them on its own How realistic do you think that scenario is?

executablebooks essentially already has no authority to make changes to markdown-it-py; it is a port of markdown-it, so can only make changes that mirror any upstream changes in that. In fact, moving to a more focussed organisation, will mean it will be better maintained and less susceptible to bugs

If so, perhaps we should define a level of "stability" that markdown-it-py reaches before spinning it off into a standalone project?

It has already reached this stability; v1.0.0 was released in May 2021

Have we had many instances in the EBP where we needed changes in markdown-it-py quickly in order to fix bugs / make releases / etc in the MyST Python ecosystem?

No, not since markdown-it-py has been stable