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

Implement feature to encode and retrieve signac elements by URI. #189

Draft
wants to merge 10 commits into
base: feature/integrated-queries
Choose a base branch
from

Conversation

csadorf
Copy link
Contributor

@csadorf csadorf commented May 19, 2019

Description

This feature implements the ability to encode certain signac elements as a URI which can then be used to retrieve said element with the signac.open() function.

Minimal example:

>>> uri = project.find_jobs({'foo' 0, 'doc.bar': True}).to_uri()
>>> print(uri)
signac://localhost/Users/csadorf/my_project/api/v1/find?sp.foo=0&doc.bar=True
>>> signac.open(uri)
signac.contrib.project.JobsCursor({'project': 'project', 'filter': '{'sp.foo': 0, 'doc.bar': 'True'}'})

Related to issue #96.

Motivation and Context

This change is motivated by the desire to reliably and unambiguously encode signac elements as unique text-strings. It is much easier to copy & paste such a URI and store it somewhere, instead of awkwardly JSON-encoded filter for example.

Types of Changes

  • Documentation update
  • Bug fix
  • New feature
  • Breaking change1

1The change breaks (or has the potential to break) existing functionality.

Checklist:

If necessary:

  • I have updated the API documentation as part of the package doc-strings.
  • I have created a separate pull request to update the framework documentation on signac-docs and linked it here.
  • I have updated the changelog.

@csadorf csadorf requested review from bdice, mikemhenry and a team May 19, 2019 02:11
@codecov
Copy link

codecov bot commented May 19, 2019

Codecov Report

Merging #189 into feature/integrated-queries will decrease coverage by 1.24%.
The diff coverage is 37.17%.

Impacted file tree graph

@@                      Coverage Diff                       @@
##           feature/integrated-queries     #189      +/-   ##
==============================================================
- Coverage                       65.03%   63.79%   -1.25%     
==============================================================
  Files                              37       38       +1     
  Lines                            5554     5626      +72     
==============================================================
- Hits                             3612     3589      -23     
- Misses                           1942     2037      +95
Impacted Files Coverage Δ
signac/__init__.py 100% <100%> (ø) ⬆️
signac/contrib/filterparse.py 67.59% <26.08%> (-10.06%) ⬇️
signac/uri.py 30.43% <30.43%> (ø)
signac/contrib/project.py 87.29% <48.27%> (-2.89%) ⬇️
signac/contrib/job.py 85.82% <50%> (-4.65%) ⬇️
signac/core/json.py 81.57% <0%> (-13.16%) ⬇️
signac/common/errors.py 72.22% <0%> (-11.12%) ⬇️
signac/contrib/indexing.py 73.77% <0%> (-1.48%) ⬇️
signac/core/jsondict.py 93.86% <0%> (-1.23%) ⬇️
... and 11 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8487e60...e67ddd4. Read the comment docs.

@codecov
Copy link

codecov bot commented May 19, 2019

Codecov Report

Merging #189 into feature/integrated-queries will increase coverage by 0.17%.
The diff coverage is 80.6%.

Impacted file tree graph

@@                      Coverage Diff                       @@
##           feature/integrated-queries     #189      +/-   ##
==============================================================
+ Coverage                        65.1%   65.28%   +0.17%     
==============================================================
  Files                              37       38       +1     
  Lines                            5574     5657      +83     
==============================================================
+ Hits                             3629     3693      +64     
- Misses                           1945     1964      +19
Impacted Files Coverage Δ
signac/__main__.py 0% <0%> (ø) ⬆️
signac/contrib/import_export.py 84.93% <100%> (ø) ⬆️
signac/contrib/schema.py 89.16% <100%> (ø) ⬆️
signac/contrib/linked_view.py 85.71% <100%> (ø) ⬆️
signac/__init__.py 100% <100%> (ø) ⬆️
signac/contrib/job.py 90.15% <50%> (-0.32%) ⬇️
signac/uri.py 78.26% <78.26%> (ø)
signac/contrib/project.py 89.91% <84.09%> (-0.18%) ⬇️
signac/contrib/filterparse.py 84.8% <89.87%> (+3.35%) ⬆️
... and 3 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 99a5847...8750e88. Read the comment docs.

@csadorf
Copy link
Contributor Author

csadorf commented May 19, 2019

@bdice Is this something that we can integrate with dashboard?

csadorf added 10 commits May 21, 2019 12:32
* Keep signac shell command history on a per-project basis.

Resolves issue #134.

* Update changelog.

* Fix Py27 incompatibility.

* Readline module not fully implemented for PyPy.
This patch enables the search for jobs with a statepoint- and document-
combined filter. To specify whether a key is a statepoint- or a
document-key use prefixes 'sp.' and 'doc.' respectively. No prefix is
equivalent to the 'sp.' prefix.

This patch is backwards compatible with the exception that the index
scheme was slightly modified.
To canonicalize all job-find filters at the JobsCursor stage.
@bdice
Copy link
Member

bdice commented May 29, 2019

@bdice Is this something that we can integrate with dashboard?

Probably, but I'm not sure if it even makes sense if the URIs require absolute paths. Is there a "relative path" variant of this planned? Like a Project.open(...)?

@csadorf
Copy link
Contributor Author

csadorf commented Jun 7, 2019

@bdice Is this something that we can integrate with dashboard?

Probably, but I'm not sure if it even makes sense if the URIs require absolute paths. Is there a "relative path" variant of this planned? Like a Project.open(...)?

Yes, Project.open(...) is already implemented as part of this PR.

@csadorf csadorf removed request for a team, bdice and mikemhenry July 5, 2019 14:02
@b-butler b-butler added the enhancement New feature or request label Jul 5, 2019
@b-butler b-butler added this to the v1.2.0 milestone Jul 5, 2019
@csadorf csadorf modified the milestones: v1.2.0, v1.3.0 Jul 5, 2019
@bdice bdice added this to the v1.4.0 milestone Dec 6, 2019
@bdice bdice removed their assignment Jan 6, 2020
@bdice bdice removed this from the v1.4.0 milestone Feb 27, 2020
@mikemhenry mikemhenry added this to the v1.5.0 milestone Apr 8, 2020
@mikemhenry
Copy link
Contributor

I think this will be a really great feature, I've added it to the milestone for v1.5

from ..core import json
from ..common import six
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can get rid of the py2/3 boiler plate

@vyasr
Copy link
Contributor

vyasr commented Apr 25, 2020

We should revisit this PR after #188 #332 is merged, it is pretty close to complete. As discussed with @csadorf, it might be beneficial to get this reviewed by someone more experienced with working with RESTful APIs (i.e. a web developer) to make sure that the URIs we're proposing make sense. @bdice @mikemhenry in any case we should plan to discuss plans for this PR at the dev meeting on Monday.

@csadorf csadorf added the blocked Dependent on something else label Apr 26, 2020
@csadorf
Copy link
Contributor Author

csadorf commented Apr 28, 2020

Brief note: We should probably directly support IRIs as a superset of URIs.

@bdice bdice modified the milestones: v1.5.0, v1.6.0 Jun 25, 2020
@vyasr vyasr modified the milestones: v1.6.0, v2.0.0 Sep 16, 2020
@vyasr vyasr mentioned this pull request Feb 26, 2021
12 tasks
@csadorf
Copy link
Contributor Author

csadorf commented Mar 25, 2021

@vyasr This is no longer blocked as #332 is merged, correct?

@vyasr vyasr removed the blocked Dependent on something else label Mar 25, 2021
@vyasr
Copy link
Contributor

vyasr commented Mar 25, 2021

Correct, this is no longer blocked. However, at this point I think we should plan this as a 2.1 feature so that we can focus our immediate efforts on finishing up the changes required for 2.0. I think this is the next major feature on the docket, though.

@csadorf csadorf modified the milestones: v2.0.0, v2.1.0 Mar 26, 2021
@stale
Copy link

stale bot commented Jun 2, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jun 2, 2021
@csadorf csadorf added the pinned Instructs stale bot to ignore this issue. label Jun 3, 2021
@stale stale bot removed the stale label Jun 3, 2021
@tcmoore3
Copy link
Member

@vyasr and @csadorf, is this still more appropriate as a 2.1 feature, or can it go into 2.0?

@csadorf
Copy link
Contributor Author

csadorf commented Aug 10, 2021

I don't know how much more work needs to be done here. I'd leave it up to the judgement of @vyasr .

@vyasr
Copy link
Contributor

vyasr commented Sep 29, 2021

Sorry for not getting back to this any sooner. I think this is still more appropriate for 2.1. We have enough to get done to get us to a clean state for 2.0 that we'd be better served getting our ducks in line for that and then coming back to this in 2.1.

@b-butler b-butler added the good first issue Good for newcomers label Feb 13, 2023
@bdice bdice removed this from the v2.1.0 milestone Jul 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers pinned Instructs stale bot to ignore this issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants