hey @jcrist!

My first instinct is that I'm not super excited about splitting this up into multiple repositories. This repo is generally pretty stable, and as you can see from #28 I haven't had a ton of bandwidth lately for issue triage/packaging/release maintenance, so creating twice the amount of work for releases doesn't sound great.

That said, if you were willing to help out with some of that maintenance (at least for whatever new home HybridContentsManager found), I'd be willing to consider splitting it out, especially if you were willing to help out with getting CI/release tooling back in shape for the split repo. Without having put too much thought into it, my preference would probably be to maintain two packages in this repo: one named something like jupyter_contents_tools (containing hybrid contents and some of the shared utility code), and the other being pgcontents, which would depend on jupyter_contents_tools and add postgres-specific stuff. For testing purposes, I'd probably want to leave most or all of the tests in pgcontents to be able to verify that HybridContentsManager works with a nontrivial alternative contents manager.

Pull HybridContentsManager out to own package #50

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions