Future of wagtail-import-export
vsalvino opened this issue · comments
Hello maintainers,
I see this package has been replaced by the much more robust wagtail-transfer.... which is used for moving content between two wagtail sites.
However we currently use this package not for moving between sites, but for providing upload/download of content from a single wagtail site (for example, mass importing product pages or location pages which were generated in a 3rd party system, or mass exporting them for consumption by a 3rd party system).
Would you be open to having wagtail-import-export morph into purely a raw upload/download package, and deprecating the transfer functionality in a future version? Or does wagtail-transfer already handle both scenarios?
We would be able to take on the maintenance burden of this package since we are already using it and would either have to fork it or rewrite it going forward. Or we could contribute the necessary file upload/download pieces to wagtail-transfer if you think that would be more relevant.
Hi @vsalvino,
The original proof-of-concept development of this package helped us to frame our thinking about the challenges and solutions of moving content between instances (typically either Staging to Production or vice versa). That's led to wagtail-transfer as an evolution, so we won't be maintaining or extending it further.
wagtail-transfer addresses key issues that this package lacks for transfer, e.g. transferring related content such as images and documents, updating rather than duplicating previously transferred content and ensuring referenced content remains correctly wired up.
Although the package was called wagtail-import-export it was intended for transfer between instances, exporting from one and importing into another (wagtail-export-import might have been a better name 😄 ), rather than for one instance. The export of a JSON file for transfer was the simplest way to experiment during the proof-of-concept development. Then, the use of the public Page API as a way to transfer pages was a relatively quick enhancement to make for regular usage. wagtail-transfer won't support the file export/import mechanism (image and document transfer would be just one difficulty here), instead focusing on transfer by its own, dedicated, secured, API.
It's great that you still find the package useful and are happy to take on the maintenance. Forking the package might be the best way forward, although it leaves open the question of publishing the package to PyPI under its current name (where we're currently the PyPI package maintainer).
Would you want to keep the name or just take the current code as the starting point for a new package?
(Given the use cases you've got for the package you might find wagtail-airtable of interest. It's a relatively new package for importing/exporting pages and models to/from Airtable sheets, keeping them in sync. It's useful for bulk creation and transfer to 3rd party systems.)
@vsalvino, I've just remembered where I'd seen that you (CodeRed) use import-export: https://docs.coderedcorp.com/cms/features/import_export.html
where you've added support to import from CSV.
If you did want to keep the name and publish to PyPI we should be okay to make you the package maintainer.
Thanks for the info @nealtodd . I think we will fork for now... we may either end up vendoring it if we only need a small subset of functionality, or we will provide a pull request here with proposed changes if we want to go down the path of continuing releases/maintenance of the pypi package.
I love the collaborative tone of this conversation. Thanks to all who contribute.