Add myst-nb recipe

[chrisjsewell]

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml"
• License file is packaged (see here for an example)
• Source is from official source
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged)
• If static libraries are linked in, the license of the static library is packaged.
• Build number is 0
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details)
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/myst-nb) and found it was in an excellent condition.

[chrisjsewell]

Currently blocked by conda-forge/jupyter-cache-feedstock#2

[scopatz]

Isn't this a duplicate of #12484

[chrisjsewell]

Isn't this a duplicate of #12484

Well yes and no.
As with conda-forge/jupyter-cache-feedstock#2, I'm the author/owner or the package and I don't know who @anirrudh is 😬
I'm sure he is well intentioned, but should it not be conda-forge policy, to ensure that the owner(s) of a package are at least notified if someone other than them is adding their package?

[chrisjsewell]

In fact this is also the same for sphinx-book-theme, sphinx-comments, sphinx-thebe and sphinx-togglebutton (see https://github.com/orgs/conda-forge/teams?query=%40anirrudh), which are all owned by https://github.com/executablebooks.
Again, I intended to add them anyway, so it's not a massive issue, but I'm a bit perplexed that I have only just found out about this and now have to go and ask for maintainer status on my/the orgs own packages.

cc @choldgraf

[scopatz]

tl;dr I'd be happy to merge whichever of these PRs is functional first.

But basically, conda-forge is a redistribution of (mostly) open-source software. We welcome anyone to help participate and package the world. Often times the original authors are uninterested or unaware of our packaging efforts. It is great when package authors also want to be recipe maintainers! As a friend and colleague, I am sure that @anirrudh would welcome you as a maintainer. Most people in this community are happy to see more maintainers join recipes.

[chrisjsewell]

I don't want to dwell on this, because generally conda-forge is great, and you guys do great work, but...

surely, as the author of the package, if I want to be the recipe maintainer then I should not need to get anyones permission, I should just be added?

[scopatz]

surely, as the author of the package, if I want to be the recipe maintainer then I should not need to get anyones permission, I should just be added?

Right, while we don't have a specific policy on this, I cannot point to a single case in practice where a package author has ever been denied a request to maintain their own package. And even more broadly, it is exceedingly rare for me to see a request to be added as a maintainer be denied for any reason whatsoever. This is kind of a non-issue, IMO. So if you want to be a maintainer, just ask! It is that easy 😉

[chrisjsewell]

Ok cool well I've made all the PRs to add me as a maintainer.
@anirrudh I'd just ask, please don't merge any version updates without making double sure that the version pinning are updated 🙏
This is the main frustration I have with conda environment resolution (maintainers not properly pinning their packages), and is why I generally like to be the main person in charge of maintenance

[chrisjsewell]

@scopatz you can merge now

[scopatz]

Ok done! You should please consider adding @anirrudh as a maintainer to these packages as well, if he wants. We are all working towards the same goal here.

[choldgraf]

+1 from me to adding as many maintainers as are interested in helping keep this updated. Rather than ensuring quality control by bottlenecking on individuals, I think we should do so by having clear documentation about what needs to happen before changes are merged etc

[chrisjsewell]

Thanks @scopatz, just please consider dropping package authors a courtesy @, if it is not them adding the recipe 🙏 (you don't have to wait for a response, but at least then they know what is happening with their package)

[scopatz]

That is not a policy that I think we can keep up with, unfortunately. We are a volunteer community of people trying to package the world. I do really appreciate the effort and willingness that you have put in by contributing conda-forge, though, @chrisjsewell! Thanks again!

[chrisjsewell]

I don't see this as any different to the rest of the nominal PR checks, it would not be for you to but but the PR author, just add a check box:

• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there
• An attempt has been made to inform package authors, if they are different to the maintainers

[scopatz]

We try to make things as easy as possible for recipe/feedstock maintainers. We don't want to add any roadblocks that would take ??? amount of time. Our users / developers are already frustrated that it can take an hour to get a package onto the channel once the PR here is merged.

I think the difference with the maintainers is that we want positive consent before adding them to a repo. For package authors, they have already given their consent by publishing under a license that allows redistribution. If package authors want to control distribution they should choose a license which restricts that. It might be nice to inform package authors, but I don't think the mechanics of it would work in practice.

[chrisjsewell]

I'm just struggling to understand why you think this is any more difficult than writing in a comment: hey @chrisjsewell just to let you know we are adding your package to conda-forge 😄

It takes 5 seconds. You could even add it in to the conda-forge bots, then it would take 0 seconds

[scopatz]

Well for example, not all of our packages are on github or pypi, where would we store the record of the conversation, who gets counted as an author (anyone who ever committed? How do you identify who issued the package?), and more I am sure.

Don't get me wrong, I think it would be great if there was some system that worked for this! I don't want to dissuade anyone from working on these kinds of notification issues. If someone wanted to contribute to conda-forge in this way and to hammer out all of these issues that would be awesome.

[anirrudh]

@chrisjsewell, if the issue is that I'm noted as a maintainer, we can remove me and list you as the sole maintainer. I packaged these being enthusiastic about the project (I highly believe in its value-add to Jupyter). From the perspective of an OSS project, this has been a non-issue in my experience packaging for both nix and conda. I understand you want version pins, but I tend to agree with @scopatz - there are tons of applications packaged for any given package manager, and I haven't seen this implemented anywhere (nix, dpkg, snap).

To be clear, I have no problem handing the recipes for all the dependencies of Jupyter-Book off to you. This really seems like a non-issue.

[choldgraf]

My 2 cents - I just think that it's a bit jarring as a package developer to feel like you don't have control over a "semi-official" distribution of your package. Many people treat conda-forge as an "official" source for open source packages, so to a degree it feels like giving out PyPI release rights to the first person that's willing to take them (and at least on the projects I've worked on, giving people rights to make a release usually requires a good deal of trust-building before they're given).

@anirrudh is helpful and operating in good faith, so IMO in this case it isn't an issue. However, what is to stop somebody else from "managing a conda-forge release of your package" and then over time adding new code that does things that the PyPI version doesn't? What's to stop them from saying "no, <actual maintainer>, I won't give you merge rights to the conda-forge recipe for this"? I'm partially thinking of the javascript world here, which has been burned many times by bad-faith actors.

Anyway, I had always assumed that in conda-forge, the maintainers of the "official" repository get some kind of special status when it comes to conda-forge recipes. E.g., others can maintain recipes for an OS project, but the core maintainers have the right to also maintain those recipes if they wish (as opposed to it being a first come, first served kinda deal). Maybe I am wrong there?

and I agree with you 💯 that this isn't a legal/licensing issue - if you release under MIT/BSD-3 then others can do whatever they want with it. This is more of a "heuristics to ensure good relations with upstream maintainers" kinda thing.

[scopatz]

Yeah, I was remarking to @anirrudh last night that conda-forge sits in-between a language package manager (LPM) and an OS package manager (OSPM).

... but the core maintainers have the right to also maintain those recipes if they wish (as opposed to it being a first come, first served kinda deal). Maybe I am wrong there?

Yeah, there is nothing in our governance that gives the original authors any kind of special rights. This has to-date been handled amicably by folks issuing a PR that adds them as a maintainer. To this best of my knowledge and experience this has always worked.

It is my belief that our process of review and curation helps prevent those kinds of bad-faith actors that you mention in the node world. We are still a couple of orders of magnitude off from that scale, though, so maybe that is something we should be on the lookout for as we grow.

In any event, we have an open development and governance model, so if anyone feels like there does need to be a policy put in place for any of the above issues, I recommend having a discussion on the gitter about it and perhaps putting in a CFEP.

[chrisjsewell]

To wrap this on my end, its not the end of world, but it is a little jarring to suddenly have a distribution out of your control, particularly when that distribution is something that I was looking to promote as an "official" means of installation. If the distribution doesn't work people won't go to conda-forge to complain, they will come go to the package and its maintainers.

@anirrudh I am grateful that you are enthusiastic about the project, just drop us a line next time you want to add a package and, as mentioned, just make sure to update pinnings 😄

Peace out ✌️