Skip to content
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

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

Open
chrisjsewell opened this issue Oct 8, 2022 · 5 comments
Open

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

chrisjsewell opened this issue Oct 8, 2022 · 5 comments

Comments

@chrisjsewell
Copy link
Member

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
Copy link
Member Author

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 chrisjsewell changed the title Move markdown-it-py out of EBP Proposal: Move markdown-it-py out of EBP Oct 8, 2022
@chrisjsewell
Copy link
Member Author

chrisjsewell commented Oct 8, 2022

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
Copy link
Member Author

chrisjsewell commented Jan 5, 2023

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

@choldgraf
Copy link
Member

choldgraf commented Jan 5, 2023

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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants