add noop legacy output for nteract-scrapbook

[bollwyvl]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

Notes:

• this adds multiple outputs, with an nteract-scrapbook that exists only to depend on scrapbook at the exact version (though build numbers won't be consulted)
• @MSeal if this is a terrible idea, please let me know... dagster might be the only downstream, so maybe this isn't a big deal, but renaming is always awkward

[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 (recipe) and found it was in an excellent condition.

[MSeal]

Hmm actually on second thought -- what's the motivation here for the change?

[bollwyvl]

conda-forge/dagster-feedstock#106

(the reason i am helping maintain this package in the first place 🎉 )

[bollwyvl]

Basically, I want a smooth, tested upgrade path to the 0.5 line for dagster installs

[MSeal]

More specifically why make a hollow reference, over changing the downstream to use the new name? We version separated the package name change so libraries could swap over to the new minor version without disrupting pulls from the old version name.

Oh did I just mess up the name change the first time around on the feedstock? Should we just drop the nteract-scrapbook output? Apologies for catching up on how feedstocks work again...

[bollwyvl]

changing the downstream to use the new name?

I haven't dug into the complexity behind what's running under the hood papermill versions, etc. But specifically, in my case, with a downstream like dagster which needs to work correctly next to airflow + graphl + grpc + dog, environments can become unsolveable (e.g. that shiny new m1 doesn't have <old version> on <old python> of <transient dependency>). I'd rather find out about that now, while trying to package, rather than when someone can't install the downstream with "fancy new feature x," because they are stuck on grpcio X.Y.Z

[bollwyvl]

mess up the name change the first time around on the feedstock?

Nope, what you did is exactly right, it just means that no downstreams will ever pull new versions.... and installing both, next to each other, would break the world.

[MSeal]

If it makes the world simpler for you, I'm OK merging. I do dislike dual package name patterns because it's confusing and upstream packages should really be able to control their versions and naming without indefinitely maintaining older patterns. But I'm less familiar with convention here with conda feedstocks so I'll defer to you. Just wanted to bring it up as what I'd see as an anti-pattern and maintenance concern down the road.

[bollwyvl]

Indeed, my world is simpler now.