-
Notifications
You must be signed in to change notification settings - Fork 31
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
issues with core data #166
Comments
Is this client logged in? I am unable to reproduce the bug. the This call works for me (with no credentials):
Is there something else I can try to repro this bug? |
This could be related to AWS credentials on your machine, assuming that's where you ran it. I would also try |
thank you @akarve! that worked on my machine, but the issue was brought to my attention by a student, so I'll wait for final confirmation. Like I said, the CI worked fine, and the package was cached on my machine so I never noticed, but was admittedly very confused when I couldn't manage to solve the issue on the student's machine, then encountered the same issue in a fresh environment on two of my own.
|
hm. looks like her issue is slightly different. Here's the trace
|
I would guess that the user has a bad credentials file. You could try moving or renaming that file as an isolation. i.e. all calls to a public bucket should just work if the user is fully anonymous. The hard thing about the issue you're encountering is that boto3 (underneath Quilt) has a complex fallback pattern and keeps looking for credentials, and sometimes those credentials are bad (what I'm seeing above) or don't have access to the public bucket. |
I did not find ".aws" file in my home directory and iam using python 3 still facing the below issue. (geosnap) suchitras-mbp:geosnap suchitrap$ python
During handling of the above exception, another exception occurred: Traceback (most recent call last): Please can anyone help me with this. |
@knaaptime Is @suchitrapithavath which operating system and python version are you using? |
it looks for the package locally then falls back to streaming. I think the answer is no, in this case that wouldnt be expected to install the package. From there I can add another handler for a |
Sounds like |
for convenience we have essentially a dataset class that provides access to our quilt datasets as methods so if you call datasets.tracts_2000() and you have already installed the package, you'll get the local version, otherwise you get the the idea being that power users probably want the data available locally, so they have the option to cache the census data to their local machine (using the On a fresh install, the first import attempt would always fail, but we don't know whether users have called |
On a fresh install of geosnap, when working through the guide I'm hitting:
|
I would like to repro but, at the start of the User Guide, this line is crashing the Jupyter Kernel.
I am running the recommended installation procedure on conda from I do notice an old-ish version of Quilt in This is what the kernel bombing looks like:
|
we just moved that up to the top level and i forgot to edit that section of the guide. You can do |
I just updated the quilt version on conda-forge today as well, so new installs should pull quilt 3.1.5 on from here on, but might take an hour or two |
OK can you point me to the code sections where you specify the Quilt packages and versions that you interact with? |
also bombing for me: |
everything happens in this class. I'll need to look into why that import fails |
(again, the weird thing is CI is passing fine, and it tests both streaming and local versions of the packages) |
closing this as I've never been able to reproduce and the student who raised it hasn't run into it again. For good measure, we've also moved everything over to https://open.quiltdata.com/b/spatial-ucr anyway |
this is odd!
geosnap depends on census data stored in our quilt bucket. Currently, our CI can grab this data just fine. If you try and collect data from a fresh install of geosnap, however, you wont be able to pull any data down
I think this is because quilt has moved over to a different infrastructure and I need to migrate our packages. But, again, it's super strange that Travis has no problem (and part of the reason I didn't notice for so long)
I havent touched our quilt bucked in several months, so I'll need to investigate a bit. Though, I just logged into the quilt slack for the first time in months and judging from the conversations I missed with @akarve and @kevinemoore, it looks like i just need to move our packages into the newer opendata bucket
The text was updated successfully, but these errors were encountered: