Releases: qri-io/qri
prune_norwegian_buhund
Most of 0.5.2 is under-the-hood changes that make qri work better. We've put a lot of time into our test suite & refactoring our existing code, which will set the stage for dev work to move a little faster in the coming weeks 😄.
🚚 IPFS repo migration
We've updated our IPFS dependencies from go-ipfs 0.4.15 to 0.4.17. Between those verions the structure of IPFS repositories changed, and as such need to be migrated. If this is your first time installing Qri, you won't have an issue, but if you're coming from Qri 0.5.1 or earlier you'll see a message after upgrading that'll explain you'll need to install go-ipfs to update your repo. We know this is, well, not fun, but it's the safest way to ensure the integrity of your underlying IPFS repo.
red_violet_belgian_tervuren
Ok ok so now we have a formal 0.5.1 release. Maybe this should be 0.6.0 given the magnitude of visualizations, but meh, we're calling it a patch.
📊 Delight in Data with HTML-template visualizations
For a little while we've been experimenting with the qri render as a way to template data into html. The more we've played with it, the more we've come to rely on it. So much so, that we think templates should become a native component of datasets. For this we've added a new section to the dataset definition called viz, which is where you specify a custom template. a dataset.yaml file that specifies viz will look something like this (These details are always avilable with the handy qri export --blank):
# use viz to provide custom a HTML template of your dataset
# the currently accepted syntax is 'html'
# scriptpath is the path to your template, relative to this file:
# viz:
# syntax: html
# scriptpath: template.html
A template can only be a single file. So your template can't reference a local "style.css" file for now. But! You're more than welcome to write HTML that grabs external resources, like getting jQuery or D3, or your favourite charting library off a CDN.
When you supply a template, the Dataset itself is handed back to you, and we use golang's html/template package to render. Here's a simplified example:
<html>
<body>
<h1>{{ .Meta.Title }}</h1>
<p>{{ .Meta.Description }}</p>
<ul>
{{ range .Body }}
<li>{{ . }}</li>
{{ end }}
</ul>
</body>
</html>This would print the Title & Description from your dataset's metadata. If your dataset was a list of strings, each entry would be printed out as a list item.
Moar Better Frontend
We're so into viz, we've completely overhauled the frontend to put custom templates front-and-center for datasets. Be sure to take the new frontend for a spin by visiting http://localhost:2505 while qri connect is running.
We've chosen to invest time in viz because we think it brings an important moment of delight to datasets. Without it, all of this data stuff just feels like work. There's something truly magical about seeing your data rendered in a custom page that makes all the munging worthwhile.
timberwolf_azawakh
0.5.1 is a release candidate to get a few important details out the door to demo at the wonderful our networks conference in Toronto. we antipate further changes before cutting a proper 0.5.1 release, which we'll properly document. More soon!
rufous mastiff
Who needs patch releases!? In version 0.5.0 we're introducing an initial search implementation, a few new commands, rounding out a bunch of features that warrent a minor version bump with some breaking changes. Because of these breaking changes, datasets created with v0.4.0 or earler will need to be re-created to work properly with this version.
🔍 Registry Search Alpha
We're still hard at work on getting registries right (more on that in the coming weeks), but for now we've shipped an initial command "qri search", that'll let you search registries for datasets. The way we see search working in the future is leveraging registries to build indexes of published datasets so you can easily search for datasets that have been published. We have a lot of work to do around making sure those datasets are available for download, but feel free to play with the command to get a feel for where we're headed with search.
use & get commands
working with the command line, it can get really irritating to constantly re-type the name of a dataset. To help with this, we've added a new command: qri use, which takes it's inspiration from database "use" commands that set the current database. qri use takes any number of dataset references as arguments, and once a user has set a selection with qri use, they become the default dataset names when no selection is made.
Around qri HQ we've all come to love the ease of working with the qri config command. qri config get shows either the whole configuration, or you can provide a dot.separated.path to scope down the section of config to show. qri get takes this idea an applies it to datasets. qri get meta.title me/dataset_name will get the title from metadata, and like the config command, it's output can be switched from YAML (default) to JSON. qri get also accepts multiple datasets, which will be combined into
new skylark html module
We're still working on a proper html module for skylark transforms with an API that pythonists will be familiar with, but in the meantime we've added in a basic jquery-like selector syntax for working with HTML documents.
"Data" is now "Body"
This is a breaking change we've been hoping to get in sooner-rather-than-later that renames the Data field of a dataset to Body. From here on in we'll refer to the body of a dataset as it's principle content. We think this langauge helps show how datasets are like webpages, and cutw down on use of an ambiguous term like "data".
Thinking about qri as an importable library
Finally, in what is more of a symbolic change than anything else, we've renamed the core package to lib to get us to start thinking about qri as an importable library. Next week we'll publish a new project aimed at writing tutorials & docs with an associated test suite built around datasets that uses qri as a library. We hope to use this project to mature the lib package for this use case.
rose madder finish spitz
We're going to start writing proper release notes now, so, uh, here are those notes:
This release brings a big new feature in the form of our first transformation implementation, and a bunch of refinements that make the experience of working with qri a little easier.
Introducing Skylark Transformations
For months qri has had a planned feature set for embedding the concept of "transformations" directly into datasets. Basically transforms are scripts that auto-generate datasets. We've defined a "transformation" to be a repeatable process that takes zero or more datasets and data sources, and outputs exactly one dataset. By embedding transformations directly into datasets, users can repeat them with a single command, keeping the code that updates a dataset, and it's resulting data in the same place. This opens up a whole new set of uses for qri datasets, making them auditable, repeatable, configurable, and generally functional. Using transformations, qri can check to see if your dataset is out of date, and update it for you.
While we've had the plan for transformations for some time now, it's taken us a long time to figure out how to write a first implementaion. Because transformations are executable code, security & behavioural expectations are a big concern. We also want to set ourselves up for success by choosing an implementation that will feel familiar to those who do a lot of code-based data munging, while also leaving the door open to things we'd like to do in the future like parallelized execution.
So after a lot of reasearch and a false-start or five, we've decided on a scripting language called skylark as our base implementation, which has grown out of the bazel project at google. This choice might seem strange at first (bazel is a build tool and has nothing to do with data), but skylark has a number of advantages:
- python-like syntax - many people working in data science these days write python, we like that.
- deterministic subset of python - unlike python, skylark removes properties that reduce introspection into code behaviour. things like
whileloops and recursive functions are ommitted, making it possible for qri to infer how a given transformation will behave. - parallel execution - thanks to this deterministic requirement (and lack of global interpreter lock) skylark functions can be executed in parallel. Combined with peer-2-peer networking, we're hoping to advance tranformations toward peer-driven distribed computing. More on that in the coming months.
A tutorial on how to write skylark transformations is forthcoming, we'll post examples to our documentation site when it's ready: https://qri.io/docs
dataset.yaml, and more ❤️ for the CLI
For a while now we've been thinking about datasets as being a lot like web pages. Web pages have head,meta and body elements. Datasets have meta, structure, commit, and data. To us this metaphor helps reason about the elements of a dataset, why they exist, and their function. And just like how webpages are defined in .html files, we've updated the CLI to work with .yaml files that define dataests. qri export --blank will now write a blank dataset file with comments that link to documentation on each section of a dataset. You can edit that file, save it, and run qri add --dataset=dataset.yaml me/my_dataset to add the dataset to qri. Ditto for qri update.
We'd like to encourage users to think in terms of these dataset.yaml files, building up a mental model of each element of a dataset in much the same way we think about HTML page elements. We chose yaml over JSON specifically because we can include comments in these files, making it easier to pass them around with tools outside of qri, and we're hoping this'll make it easier to think about datasets moving forward. In futures release we plan to rename the "data" element to "body" to bring this metaphor even closer.
Along with dataset.yaml, we've also done a bunch of refactoring & bug fixes to make the CLI generally work better, and look forward to improving on this trend in near-term patch releases. One of the biggest things we'd like to improve upon is providing more meaningful error messages.
stizza wirehaired vizsla
chore(release): release v0.3.2 Merge pull request #402 from qri-io/v032
napier green miniature american shepherd
chore(release): release v0.3.1 Merge pull request #371 from qri-io/v031
sienna american hairless terrier
This release brings two big changes:
- overhaul of peer-2-peer communication
- unified
configcommand
Breaking Changes
Because this is a young codebase & we're moving quickly, we've opted to skip backwards compatibility with 0.2.1, please move / delete everything at $QRI_PATH (or $HOME/.qri if one isn't set) before upgrading.
mulberry whippet
Webapp! (experimental) CBOR! So many things!
royal fuchsia chihuahua
v0.1.2 chore(release): release 0.1.2 (#272)