Open chrisjsewell opened 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.
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
This has now been outstanding for many months, @executablebooks/steering-council please could you advise on moving forward with this thanks?
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?
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
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