-
-
Notifications
You must be signed in to change notification settings - Fork 106
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
embed sixified jsondate into jurisraper/lib #249
base: main
Are you sure you want to change the base?
Conversation
Neat! I just wrote this issue: rconradharris/jsondate#8 in hopes that they'll transfer the code to us, but I'm doubtful they get Github notifications. Let's give it a few days. If they don't respond, I think I'd rather fork jsondate and release freelawproject/jsondate2 or something instead of vendoring it. Seems better for the community and for separation of concerns. |
Good luck getting a response! There seems to be no response to any issue or pr in the repo. The repo is four commits deep, with the latest being a few years ago. If it comes to a fork, you can use the one I made yesterday, https://github.com/umeboshi2/jsondate. I agree that forking is better than embedding. I just did this since the package is so small and simple, and upstream is very, very quiet. |
looks like this fork has six implementation and this fork has py3 support While I commend to effor to fork yourself @umeboshi2, I'm wondering if an institutional fork might be more robust. If, for example, you ever go silent on GH, then we are in the same position with your fork. But, if the fork is owned by an institution that we know will remain active, and which has multiple developers, then I think there's less likelihood of the project being abandoned again--and I think FLP checks both of these boxes. |
Yes, I created the fork because I only saw nitz's fork on pypi, but that fork is not py2 compatible. Ilya's fork seems to be better since it uses six and should work for each python version. However, with respect to an institutional fork, it seems that rharris is the better option, since he's listed as part of HP. Nevertheless, on the overview pages, it seems that Ilya is the most active on github of all of these candidates. Interestingly, it seems that the amount of ascii characters in just this conversation exceeds the amount of characters in the actual code being discussed. |
"Interestingly, it seems that the amount of ascii characters in just this conversation exceeds the amount of characters in the actual code being discussed." This is a hilarious observation |
Feel glad that we aren't using nodejs, where many important packages are essentially one-liners. :) Example: https://github.com/then/is-promise
|
I think we have a decision from email to create freelawproject/jsondate3 or 6 or something. @umeboshi2 can you tell me what repo to make? I'll give you permissions to set it up, and then we can do the pypi rigamarole. |
I sent a PR to nitz at nitz14/jsondate#1 late last night. He's already uploading to pypi using "jsondate3". If he accepts the PR and uploads a new version, the problem will be solved. The only change I made between his fork and my fork, excepting the javascript date handling, is to replade If he doesn't respond, a new repo can be made under freelaw and filled with my fork. My fork didn't include the javascript format feature. If the new repo is to upload to pypi, we can't use "jsondate3", though "jsondate6" should be available. I'm not sure how you want to do the pypi rigamarole, but I have been using the travis deploy feature. I started using the audreyr/cookiecutter-pypackage repo to start new python packages, which makes pypi uploads a bit easier. I actually use my own fork for yaml config, instead of json config. |
Oops, I forgot to mention that it would be nice to wait a little bit for nitz to see if he's agreeable before adding yet another "jsondate" package to pypi. |
Well, nitz does not look like a very active Github user, but we can hope. |
True, but I feel we can wait a little bit. The jsondate package isn't really holding things back from juriscraper being py3 capable. There are also json comparison issues when testing in py3 that are more important. Since that "futureproofing" PR has been merged, I was hoping one of y'all would run the tests in py3 and provide some suggestions on what to do about the json compare problems. The jsondate problem will be easy to solve, regardless of which direction we take, but even so, the json compare problem will still persist. |
Also forgot to mention that opinion scrapers don't load when testing in py3, but produce a failure. I submitted the "futureproofing" PR because the code changes were needed, and the tests passed in py2, but more work will need to be done to get juriscraper working with py3. It's been a while since I ran the tests in py3, so I forgot the details. I ran them again a minute ago, so here are some snippets of the results:
|
Small note here that I forked and released a new tool called jsondate3-aware: https://pypi.org/project/jsondate3-aware/. I'll land it as part of Juriscraper in a bit, but it should help here once it's ready. |
|
In another discussion, I took note that jsondate wasn't compatible with py3.
I decided to fork the repo and fix it, but since the package consists of a single small
__init__.py
file and a single test file, I decided it would be just as easy to embed it into the project. Porting the package to use six was pretty straightforward, and it seems that the upstream repo is effectively dead.It seems that jsondate is only being used i pacerdocket and tests/test_pacer, so I don't think that this code will be too difficult to maintain in the future. The test module adds 9 tests, which are the same tests as upstream, though slightly modified to use six for future capability. The tests should execute at the very end of the test run.