Open rmaronson opened 4 years ago
Hmm let's find all hardcoded urls first and document them here, then think about the different needs of each.
I'm distracted rn, but here's a start:
did a very quick scan and didn't find anything else in the py
files, but inside dashboard
all of */list.js
included hard-coded calls to /api/xyz
, and many of the html templates include those js
files with absolute urls
presumably the html templates could be handled with more aggressive use of {{url_for}}
(like in https://github.com/NYUCCL/psiTurk/blob/5891530a914694aeae877cdd413ce674f7605007/psiturk/dashboard/templates/dashboard/base.html#L13
not sure so much about the js. it doesn't seem like a great plan to force them to be templated if they don't need to be otherwise.
I'm not opposed to the js files being templated, especially since there's already this weird thing that happens where psiturk.js is loaded as a string from here and here and then served as "static" route here
So it's already templated, basically, even if someone has already run psiturk-setup-example
, they'll always have the psiturk.js that's bundled with their current psiturk version. For better or worse. Unless! Unless they copy psiturk.js into their experiment's 'static/' folder.
Also, I think those /api
calls will be relative to the site root, since the api gets registered as a blueprint. I'll have to look more closely at the javascript in there though.
New university, but I just ran into this issue again. Is there interest in fixing this? I might be invested enough to make a PR but it would need to be checked and want to make sure this would get supported if I do.
I'm afraid that this project seems to have mostly been abandoned. I even volunteered to review PRs but no response. At this point, I've forked the project to customize to my own needs. I recommend doing the same, unfortunately.
On Tue, May 21, 2024 at 9:31 PM Reuben Aronson @.***> wrote:
New university, but I just ran into this issue again. Is there interest in fixing this? I might be invested enough to make a PR but it would need to be checked and want to make sure this would get supported if I do.
— Reply to this email directly, view it on GitHub https://github.com/NYUCCL/psiTurk/issues/425#issuecomment-2123474505, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM5SQMYTOFNKUZBK2EOK33ZDO4JTAVCNFSM4NYXLEQ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJSGM2DONBVGA2Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Indeed. This project hit a rough spot when I left academia a few years ago, and the nyuccl lab said they'd been using a very old version of psiturk for years and then they had chosen to roll their own new platform instead of migrating to the latest psiturk. With the project under the name of the nyuccl lab, that makes it toast.
You put in your time Dave, that's for sure.
I’m happy to facilitate what people want to do to carry the torch on this, but we moved to something else internally!
On May 21, 2024, at 7:04 PM, jacob-lee @.***> wrote:
You put in your time Dave, that's for sure.
— Reply to this email directly, view it on GitHub https://github.com/NYUCCL/psiTurk/issues/425#issuecomment-2123569749, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALD4YGGOLC2YJKMG4IBW3DZDPHI7AVCNFSM4NYXLEQ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJSGM2TMOJXGQ4Q. You are receiving this because you are subscribed to this thread.
A shame; I've had good experiences with the project! I am not up to taking over the project, though if I do take on this overhaul it would be nice if it were somewhere other than in a buried fork. Are there other alternatives people know about, or are we just rolling our own? Seems a shame if so.
Yes it has been a great project and collaboration between many people over a decade! (The first version was 2013). This is a classic challenge in open source software, they require continued investment from lead developers. In my case I just need to focus on other things professionally and our workflow changed in ways that made psiturk less effective for my lab’s own purposes. But it’s still great stuff (and used even by many of my colleagues). The project just needs someone else to carry the torch. There’s many benefits to helping to lead an open source project, in terms of community and stuff. But it is a time commitment to not leave PRs un-merged, bug fixes, and things like cloud services changing their API/terms, etc.…
As I said, I’m happy to do what I can to transfer it, including if it needs to move off the nyuccl organization. But I’m too far away from the code base currently to do deal with the unmerged PRs.
t
On May 22, 2024, at 6:59 PM, Reuben Aronson @.***> wrote:
A shame; I've had good experiences with the project! I am not up to taking over the project, though if I do take on this overhaul it would be nice if it were somewhere other than in a buried fork. Are there other alternatives people know about, or are we just rolling our own? Seems a shame if so.
— Reply to this email directly, view it on GitHub https://github.com/NYUCCL/psiTurk/issues/425#issuecomment-2125914904, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALD4YCLZP5J4G73G3O2MJTZDUPLRAVCNFSM4NYXLEQ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJSGU4TCNBZGA2A. You are receiving this because you commented.
We have the use case where we have one public domain name as entry point to our lab resources, but we'd like to be able to use multiple studies. We have nginx set up to reverse-proxy to different instances of psiturk to enable different, unrelated experiments but it's not clear how to make studies differently addressable from outside. The easiest way to map to different locations would be to use an alternate path, i.e.
Unfortunately, the links within the files refer to top-level locations, so this fails (i.e. "/sync"). (Note that because of our setup, it's not easy to add additional subdomains nor open additional ports.)
Suggested resolutions:
/
(e.g.,/sync/
->sync/
), then the links will be interpreted relative to any top level directoriesprefix
option to the config file that gets supplied to each url which gets resolved in the templates and python init, similar to theurl_prefix
option in BlueprintI am happy to do this + add a PR if there is resolution on what the right approach is, but no promises that I'll be able to track down all the urls in the first pass :)