ncdulo / word_tools Goto Github PK

Automated testing has introduced, rather quickly, a bug I feared I might encounter. Intermittent failure of some lookup tests. Specifically, this has been due to lookup.wikipedia returning results in a potentially changing order. While the issue has only presented with Wikipedia, I believe it has the potential to effect any of the related functions.

This simply comes down to the dynamic nature of the web, and search results changing over time. One possible way to mitigate this effect may be to check the entire list of fragments, instead of checking them by their order in code. This would mean adding more fragments to certain areas, such as the 'top 5 result fragments', and then checking each one of them to each result. There may be a better way to do that. Look into it.

Until resolved, expect potential intermittent failures in test_lookup.py tests. Restarting the build from Travis CI seems to be a valid workaround.

Describe the bug
Once again, the Wikipedia does not seem to play nicely. The dynamic nature of results seems to be tripping me up. Again. This failure seems specific to the Disambiguation pages. test_wikipedia_disambiguation is intended to ensure we receive a DisambiguationError when we search for a known dis-ambiguous page. The test results seem to indicate that sometimes we receive that error, other times Wikipedia finds the closest matching page and returns that instead.

To Reproduce

1. Run pytest
2. Is not failing? Return to step 1.

Expected behavior
The pymediawiki module should throw a DisambiguationError for certain search terms. It does that, but it seems Wikipedia switches things around now and then. Sometimes we get it, sometimes we don't.

Additional context
This is bringing me back to Issue #2. A very similar test failure that was thought to be limited to my previous implementation. Looks like it's not totally my fault this time.

What's the deal?
After getting the new issue labels set up and working, I feel several of them are far too similar to each other for easy identification. The pairs of similar colors are the repo/enhancement, and invalid/packaging labels.

Why does it matter?
Even for me, with normal color vision, the colors are hard to discern from each other. I imagine this may be worse for people with vision problems, colorblindness, or similar. I don't like struggling to read, and labels are meat for easy identification and categorization. If they're all the same, what do they matter?

What are you going to do about it?
Update the colors! This is a very small, and simple fix that will just mean clicking the 'random' button over and over until I'm happy with the colors it spits out.

Why bother writing an issue?
This issue is solely to note so that I can keep it on my task list. Just needs a few minutes to preview some colors, check them out, and update .github/labels.yml. No need to update the labels directly on GitHub -- our push actions will handle that once pushed to this repo.

The current README is a little.. dated. Originally kind of thrown together fairly quickly. It has not been updated as the project grows. Need to get that changed. Writing an issue to keep it in memory, and to lay out some sections I would like to include.

• Summary
• Requirements
• Installation
• Usage
• Contributing/Bug Reporting
• Development Goals/Long-term

Is your feature request related to a problem? Please describe.
Currently, we have a slightly.. different method of handling our CLI entry-points. They are click commands that are called directly by setting entry-points in the setup.py file. The original intent of this was a set of short and easy to remember aliases such as wt.stoopid or wt.urban. As the project grows, this system is becoming more difficult to maintain. And has been slowly running into errors on occasion.

Describe the solution you'd like
Utilize a proper Python entry point -- through __main__.py, and branching out into individual commands from there. I would like to use a single entry-point, with a minimum of required arguments. Various providers should use similar sets of arguments, where possible.

Fully writing the main function as above, we will very likely be able to do away with cli/cli.py. That file was becoming the source of several sporadic errors. Import errors, runtime errors, strange things were happening. The code was nearly untested and most users will not want an executable style as laid out by it. The new entry-point will do away with all of that. Should provide functional, tested code with a smooth user experience.

Some potential terminal commands may include:

$ word_tools -p/--provider [prov_name] word [limit]
$ word_tools -p urban python 3
$ wt.lookup -p/--provider [prov_name] word [limit]
$ wt -p wiki 'apollo program'

Describe alternatives you've considered
The main alternative to the above of a single entry-point would be dual entry-points. One for transform providers, one for lookup providers. I don't think I like that because it feels like a re-iteration of the original system that got us in trouble to begin with. Using a single entry-point will be more extensible in that we will require less modification to include new providers.

Additional context
None required at this time.

Describe the bug
The 'Periodic Labeler' GitHub action does not seem to work in it's current configuration. I have allowed several days for it to repeatedly run, which it does. But my pull requests remain unlabelled.

To Reproduce
Steps to reproduce the behavior:

1. Create a Pull Request
2. Don't add labels
3. Wait

Expected behavior
After this action runs, unlabelled pull requests that match the patterns in .github/labeler.yml should have labels matching the rules applied. This should include pull requests of my own, and external origin.

Additional context
We may just remove this specific action, and replace with one of the other pull request label solutions. However, this will mean pull requests from other users will not be labelled against. Just a limitation of GitHub, I have read.

Is your feature request related to a problem? Please describe.
Having zero experience with Continuous Integrating/Testing until a few days ago, I feel there is a lot for me to catch up. This means I may miss some more fitting solutions in favor of a solution I find first. I feel that Travis CI may have been one of those initial solutions.

GitHub Actions provides essentially the same toolset and features, at least for my basic FOSS/personal project use. It does not entirely make sense to me that we should rely on an external service when I can handle it directly from within GitHub. Handling CI with GitHub Actions will also allow it to reside within the same scope as my other actions, under a unified interface. Sounds like a good thing to me!

Describe the solution you'd like
The most fitting solution as of now seems to be migrating our .travis.yml file over to .github/workflows/ci.yml. There may be some syntax updates, or other changes made to the file for it to work. Though I anticipate it will be fairly straightforward, possibly requiring no modifications at all to that new action.

We will also need to consider Codecov.io and it's role in this pipeline. I really enjoy the Codecov web interface, and statistics tracking. Is there an option for that on GitHub?

Describe alternatives you've considered
No alternatives considered for Travis except migration to GitHub Actions. Code coverage should be given thought. Does it remain on Codecov.io? Does it migrate to GitHub Actions as well?

Additional context
None required at this time.

Is your feature request related to a problem? Please describe.
This refactor was decided upon based on issue #2 and determining what it might take to fix. Giving that problem a good long look at, I think our current lookup module could use some love.

Describe the solution you'd like
Implement a generic factory pattern, which returns 'lookup providers' based on the API source, or data providers (Wikipedia, Urban Dictionary, etc). This should allow a greater flexibility for the end-user in how they query data from our providers, allow for a more fine-grained control over some of the common elements to each provider, and facilitate easier addition of new providers in the future.

Implementation details are not fully decided upon yet, just needed to get the base issue written up and logged here.

Describe alternatives you've considered
No alternatives considered. Only the solution we had used up until this point, which is proving harder to work with by the day.

Additional context
The decision to refactor lookup was arrived at due to issue #2. Finalizing this refactor will help in coming to a valid solution to that issue. They are slightly dependent on each other in that sense.