Skip to content

Json loader now returns str objects instead of unicode.#2524

Merged
tgamblin merged 1 commit intospack:developfrom
skosukhin:pr_json
Dec 8, 2016
Merged

Json loader now returns str objects instead of unicode.#2524
tgamblin merged 1 commit intospack:developfrom
skosukhin:pr_json

Conversation

@skosukhin
Copy link
Copy Markdown
Member

We need something like this (at least for now) because now we get unicode objects when we load from the json database. This leads to the problem of hash evaluation of already installed packages.

For example, when we do 'spack activate <python_extension>' we get the following error:
Error: Can only (de)activate extensions for installed packages.

This happens because when spack evaluates hash code, it gives yaml unicode strings and the latter, instead of returning:
{python: {version: 2.7.12, arch:...
gives this:
{!!python/unicode 'python': {version: 2.7.12, arch:

The solution is based on this: http://stackoverflow.com/a/33571117

@alalazo
Copy link
Copy Markdown
Member

alalazo commented Dec 8, 2016

Just my personal opinion: I don't think we should merge into develop PRs that are just meant to preserve old hash values. I would definitely feel differently if the JSON PR was backported on a stable release, but develop is the bleeding edge...

@skosukhin
Copy link
Copy Markdown
Member Author

@alalazo this is not about preserving old hash values. This fixes a bug in the develop. Hashes that are evaluated during the runtime do not match the hashes that are stored in the database when they should. Just try to install an extension and then activate it. For me it does not work without this commit.

@adamjstewart
Copy link
Copy Markdown
Member

@svenevs This could be the problem you mentioned when trying to active opencv+python.

@alalazo
Copy link
Copy Markdown
Member

alalazo commented Dec 8, 2016

@skosukhin Apologies, I tried a couple of installation before writing the comment above, but didn't try to activate anything, and this bug seems extension specific.

@tgamblin tgamblin merged commit 10591fb into spack:develop Dec 8, 2016
@tgamblin
Copy link
Copy Markdown
Member

tgamblin commented Dec 8, 2016

@skosukhin: Thanks!

@becker33
Copy link
Copy Markdown
Member

becker33 commented Dec 8, 2016

I tested the performance of this, the performance loss is negligible on my spack instance. (~5%, compared to the improvements JSON brought, which were 181X).

@alalazo
Copy link
Copy Markdown
Member

alalazo commented Dec 8, 2016

@tgamblin @skosukhin @becker33 I was not aware of the rabbit hole that is python 2 default string encoding vs. python 3.

I have a question about this: won't this PR go in the wrong direction if we want to be python 3 compatible? Do I understand it right that in principle it would be better to explicitly encode unicode what is now ascii and not vice-versa?

@tgamblin
Copy link
Copy Markdown
Member

tgamblin commented Dec 8, 2016

@alalazo: we probably want to use unicode everywhere when we switch to support 2 and 3. But I think that's harder than preserving the status quo at the moment. This PR makes JSON did what YAML did before. I think it's reasonably easy to switch this stuff to unicode when we're ready.

And yes it is a sad rabbit hole 😭

kserradell pushed a commit to kserradell/spack that referenced this pull request Dec 9, 2016
@skosukhin skosukhin deleted the pr_json branch December 12, 2016 15:50
@tgamblin tgamblin mentioned this pull request Mar 27, 2017
17 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants