Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

scriptPath vs scriptBytes rears its ugly head #29

Open
dustmop opened this issue Sep 3, 2020 · 0 comments
Open

scriptPath vs scriptBytes rears its ugly head #29

dustmop opened this issue Sep 3, 2020 · 0 comments

Comments

@dustmop
Copy link
Contributor

dustmop commented Sep 3, 2020

Components like readme and transform represent textual data. They work by having a path to another file which contains this text. The file may reside on the local filesystem, or on IPFS.

Sometimes, the dataset loading subsystem (dsfs) will load this file, and assign its contents to scriptBytes (base64 encoding it). Sometimes it won't, and leaves the path in scriptPath. I'm not 100% certain why this only happens sometimes, but I'm pretty sure it's due to FSI (file system integration). That is, if the file is "checked out" and has a "working directory" will lead to one outcome, and if not, then the other.

These components should have a property method called script() that will handle either scriptBytes or scriptPath and return the text as a string in either case. This means the python package will need to be able to get data off of IPFS. Probably the best way to do this, for now, is to just get qri core to do it by asking like: qri get readme.script <dataset_ref>.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant