archivesspace-labs / ArchivesSnake

A client library for working with the ArchivesSpace API
https://archivesspace-labs.github.io/ArchivesSnake/
Other
78 stars 13 forks source link

Start of the abstraction layer #6

Closed gwiedeman closed 6 years ago

gwiedeman commented 6 years ago

Still needs some work and doesn't .save() yet, but now can loop and view though most common calls.

testScript.py just demonstrates what works

helrond commented 6 years ago

This is very ✨ ✨ !

Wondering what you all think of separating out utility functions, particularly serialization stuff. I know we have a whole host of scripts that basically grab different pieces of AS content and spit them out in a CSV for review. It seems like having some easy-to-use serialization options might be super useful for folks...

pobocks commented 6 years ago

Closing this as superseded by https://github.com/archivesspace-labs/ArchivesSnake/tree/abstraction_layer

@helrond If you wanna put a brief "what I'd want out of serialization" over here, or make an issue for it (I think issue might be a better idea, long term, I've just been using the wiki as a scratchpad while it's still sketchy-time), I definitely think putting some thought and effort into that would be well rewarded. I'm not quite sure what the "separating out" part means in concrete terms, tbh - do you mean an explicit asnake.utils module with a buncha stuff put in it or something? I can def see us having something like that sometime, but most of the things we've got written fit pretty logically on our objects.. and I think objects knowing how to serialize themselves might keep it mostly that way going forward.

helrond commented 6 years ago

Leaving a comment here to close the loop: I've been thinking about this more today and - especially after a quick cruise through the technical planning page on the wiki - I'm not sure my idea is actually good. ASnake, as it's conceived now, is really a way to interact with the AS API. What you do with the outputs of that is up to you. It's tempting to suggest serialization utils like make_csv_row or something, but on further thought those things seem really out of scope and also potentially overlapping with existing packages.

gwiedeman commented 6 years ago

I think this is right but, since a bunch of us are all doing the same things, we should still share code. I'm thinking as a separate import, this way by default you write your own so you can set your own separator, etc, but you can also import make_csv_row or whatever so I don't have to look up that same stack overflow page each time I forget newline=''. This should wait until the abstraction layer is done though.