jrkong / pysearch Goto Github PK

This issue will depend on #2.

#2 will implement a single test case which will cover the test case where a user defines a single search, the search engine used and the domain of the search engine.

A brief list of missing test cases (note this will likely be incomplete):

• Individual functionality of each command line argument (search term, domain and search engine)
• Support for spaces inside the search term
• Different combinations of command line arguments and order of the command line arguments
• Verify domains that use unique search strings use those search strings (amazon search string uses /s/keywords= instead of /search?q=)

Before working on this issue please state the test(s) you plan to work on to ensure that there are no other collaborators working on the test.

pySearch currently creates and opens links that may not exist. For example, current behavior defaults the domain to .ca however there is a chance that the domain is unsupported by the search engine (consider http://stackoverflow.ca/search?q=test.

In these cases the script should give the user a message stating that the built link is invalid. After this the code should try different popular domain extensions to see if any work. If a valid domain extension exists then provide a message which informs the user of the found domain and opens the link in the browser.

I believe the most lightweight solution would be a calling ping to the subsystem shell using os.system() subprocess (instructions on replacing os.system()/example here). In theory a successful ping should return error code 0 and all other returns should signify an error.

It would be nice if we had a command line argument which let the user select the browser they open up. For example, pySearch -s test search -b firefox would open a search in Firefox even if my default browser is Google Chrome.

I would look at the webbrowser module's register function to get started.

I would love to see this feature implemented in such a way that the code is flexible with the arguments it accepts. So firefox or Firefox should be acceptable and Google, Google Chrome or chrome etc should be fine.

Currently Amazon and Twitter both have exceptions to their search strings. Amazon uses /s/keywords= to initialize a query and directly encodes spaces as %20. Twitter currently encodes spaces directly in their url. We need some way to verify that this behavior doesn't change and create a warning if it does.

Implement basic Travis CI functionality to run tests automatically.

Currently the user needs to be inside the pySearch directory to execute the script. It would be nice if we could create a script which adds the script to the environment variables.

To get started I would look at how to edit the Windows environment variable using the command prompt and attempt to execute the command through the Python script.

Note: You can call a command in the system shell using os.subprocess.

At the moment the script does not install all the required Python dependencies on the host machine. Take a look at the requirements.txt documentation for pip.

Look at Scrapy to implement basic webcrawling abilities to grab the first 3 results from a search and display them. If a user inputs a number it will open that link in a web browser.

So currently the delimiter is undecided so go with whatever you want. However there are a few things I would consider/look into when deciding on the delimiter:

• html has a few unsafe characters (I've found this article has a pretty nice list) should it be one of those, or involve one of those
• should there be a way to cancel the delimiter to allow it inside a search term?

It would be really cool if we could settle on a delimiter that is short and sweet so the user doesn't need to type much but avoids something users might search.

Let's discuss.

PySearch needs a README. This does not need to be anything complex but it should:

• Give a brief overview of the project and it's functionality
• List the command line arguments (refer to lines 7-10)

http://flake8.pycqa.org/en/latest/

If a delimiter is found, pySearch should open a new tab for each subsequent search. Take a look at the webbrowser module to get started with this.

Currently we integrated Flake8 and pep8speaks bot into pySearch. You will be able to run the flake8 locally by running flake8 . after installing it with python -m pip install flake8. This will show you a list of current errors. In addition, whenever somebody creates a PR, pep8speaks bot checks the changes that a person made with the same errors.

However, we are currently ignoring existing error in .pep8speaks.yml and setup.cfg. In order to fix these errors, please remove an error from the ignore list of both files and run flake8 . in the pySearch root directory.

List of currently ignored errors:

• E251, # unexpected spaces around keyword / parameter equals
• E265, # block comment should start with '# '
• E302, # expected 2 blank lines, found 1
• E501, # line too long (105 > 79 characters)
• F401, # '...' imported but unused (assigned to: @alexander-ponomaroff )
• W292, # no newline at end of file
• W293 # blank line contains whitespace

Please pick one error and I will assign you to the error and you can make a pull request with your fix. We will take these errors one by one, so everybody gets some practice with these and has a chance to contribute. Comment below the error that you want to work on and I will assign your name to it!

Create a script which adds python script to the user's bash profile. Things to look at to get started:

• look up the bash_profile
• think of how to change or add to the bash profile

Note: You can call a command in the system shell using os.subprocess.

pySearch does not preprocess urls. This means unsafe characters are passed directly into the search string. This is unsafe.

To fix this the text being searched needs to be processed to encode unsafe characters (info on unsafe url characters). W3Schools has a nice ascii encoding reference sheet and tester.

This is an open ended issue that will likely remain open.

At the moment only a few search engines are officially supported. pySearch defaults the search string to /search?q= which is the generic case however exceptions occur and it would be great if they are accounted for.

An example of an exception and it's implementation would be Amazon which uses /s/keywords= as it's query initializer.

While the new encoding from #8 does it's job and introduces safety to the built URLs I've found it occasionally breaks the structure of the domain specific search strings. For example, for Google spaces are denoted by the + character and a # is encoded as %23.

The current approach of URL encoding, while safe does not conform with the search string standards of different domains.

Add unit tests to pySearch. A good place to get started would be Python's default unittest module.