ilovetux / unitils Goto Github PK

I have moved pawn to its own project because it doesn't really fit in here. You can view that project here.

This issue is to remove any reference to pawn, this is especially important as installing both unitils and pawn breaks the pawn cli.

Here, we will discuss what exactly we will consider to be a Minimum Viable Product (MVP) for touch.py.

At the very least it should:

• Create a non-existant file
• Change the modified time of an existing file
• Change the access time of an existing file
• Accept a -c, --no-create flag
• Accept a -m flag to adjust only the modified time
• Accept a -a flag to adjust only the access time

Also:

• It should be documented both sphinx autodoc and a man page

We need to support a case-insensitive match in grep.py

We need to ensure that every piece of functionality makes its way into the api documentation

We also need to write a page for readthedocs for each piece of functionality we have...I'm also hoping to make these into man pages

Here I will attempt to outline the general strategy for releases of this project.

• We will adhere to semantic versioning
• Whenever a new version is available, it will be:
  • Tagged in GitHub
  • Uploaded to PyPI
  • Documentation will be updated/uploaded to ReadTheDocs.org
  • Executable binary files will be packaged with PyInstaller and added to the release tag
  • Links will be added to the project web site for downloading the executables and the source package

I am making this an issue, because I am not sure about all of this exactly. The above lists a general outline of what I think should happen, but I am open to ideas and especially tips on how all of this stuff is usually automated. I was going to put it all in the Makefile and there doesn't seem to be anything wrong with that, but if you are reading this and know of a better way, please don't hesitate to comment below.

try on setup.py

$ wc setup.py
40 79 1185 setup.py
$ wc.py setup.py
40 113 1185 setup.py

Also notice wc indents by two spaces

This makes it unusable

This issue is to discuss what is needed to achieve a Minimum Viable Product for zip.py.

NOTE I am used to working with archives through nautilus and do not have much experience with the linux zip command, so if someone knows what will be needed to achieve an MVP for this, please comment below.

I will start to read up on this utility and play around with it to find out how it really works.

I will publish once the basics are all covered and test coverage is back at 100%

This issue is to discuss the MVP for cal.py

At the very least it should:

• Display a friendly version of a calendar, default to current month
• Support most options, there are not that many and they all seem indespensible

in this section of the README.rst, we talk about testing on Windows. I have removed the dependencies which broke those tests and added the Python 3.5 environment in appveyor, so this disclaimer is outdated and needs to be removed.

Because codecov works better than what I was using python setup.py nosetests --with-coverage --cover-package unitils, I need to get test coverage back up to 100%, and now that we have compatibility between all relevant Python versions and Linux and Windows it is time to work on coverage.

This issue is to discuss the Minimum Viable Product for more.py.

At the very least it should:

• Properly handle line-wrapping
• work as a pager on Linux

Also

• Documentation

We are not at 100% test coverage, and because of our util module, we are unlikely to get back to 100% test coverage, also there are broken links.

This makes grep.py completely useless.

I'm looking at this pragmatically, I want to go after the low-hanging fruit first as I believe that will make the project immediately useful. I will keep a list here of utilities I wish to implement for the 0.7.0 release:

filesystem utilities

• cp
• find
• touch
• ls / ll
• mv
• rm
• which
• zip / unzip

Text Processing Utilities

• cat
• grep
• head
• more
• pr
• sed
• tac
• tail
• wc

utilities

• bc
• cal
• curl
• file
• shasum
• ssh
• strings
• top
• make
• md5sum
• watch
• wget

This issue is to discuss the MVP for tail.py

At the very least it should

• be able to print the last n (default to 10) lines of a file
• Support a -f, --follow flag to keep checking for "tailing" a file

This issue is to discuss what is needed for a Minimum Viable Product (MVP) for rm.py

At the very least rm.py should:

• Remove a file
• Accept a -r, --recursive flag
• Accept a -f, --force flag

Also:

• Should be documented in both autodoc and a seperate man page

This issue is to discuss the Minimum Viable Product (MVP) for unzip.py

The only thing I use this utility for is unzip -l so it must support that, if anyone has experience working with the linux unzip utility, please comment below.

I just actually pushed a "tracer bullet" into dev, but I wanted to make this feature official. What I want here is a re-imagining of AWK, but with as little work as possible.

The basic premise is that like AWK, you have patterns and actions. The patterns are regular expressions and the actions are Python code blocks enclosed in blasphemous curly-braces ("{}").

An set of input files is passed in along with a script. We then iterate through each line in each input file and when a pattern in our pawn script matches, we execute the action.

Each action has access to global variables:

• FS: The field seperator (defaults to any whitespace)
• LINE: The line we are currently on
• FIELDS: a list of the fields into which LINE is split on the FS

There are two special patterns:

• BEGIN: Matches before the first line is read
• END: Matches after all lines are exhausted

State is maintained throughout the execution of actions, this means that if an action modifies a variable then any subsequent actions which are called will have access to those modification.

Like the title says.

When simply attempting to output the contents of a file

ls lists items in left-aligned columns, filling the screen. ls.py should behave in the same way

Self explanatory, see title

We try to seek to the beginning of the file in wc in case an open file was passed in, so when stdin is piped in, we get an error since you cannot seek on stdin.

We can run profiles on demand, it is of limited (but not none) value to run it continuously.

I am opening a dev branch with the change to add in the .travis.yml file for Travis CI to test against Python 3.3 and 3.4. The builds will fail until they do not at which time I will keep the dev branch open and start working on features. The reason I am doing this is that I felt Python 3.3 and 3.4 should have been supported from the beginning, but are not at the moment. I will link back here when I open a pull-request.