I think will be nice use it for contributors build your own environment.

http://www.pip-installer.org/en/latest/requirements.html

Dose should deal with exceptions that comes from the watchdog observer, like:

OSError: inotify watch limit reached
OSError: Permission denied

These errors are triggered when the watchdog.observers.Observer.start method is called for an instance that is scheduled to watch something it couldn't watch. Similar to runner exceptions, Dose should give a proper message instead of crashing.

On Linux, when running Dose on a directory that has way too many subdirectories, watchdog raises an OSError because inotify has a limit on the number of watchers, and watchdog puts a watcher on every subdirectory:

$ mkdir /tmp/crash_dose
$ cd /tmp/crash_dose
$ cat /proc/sys/fs/inotify/max_user_watches | xargs seq | xargs mkdir
$ dose echo -n
                 *** First call ***
====================================================
         [Dose] 2016-11-27 04:10:53.223946
====================================================
Traceback (most recent call last):
  [...]
  File "/usr/lib/python2.7/site-packages/dose/_legacy.py", line 487, in start
    self._watcher.__enter__() # Returns a started watchdog.observers.Observer
  File "/usr/lib/python2.7/contextlib.py", line 17, in __enter__
    return self.gen.next()
  File "/usr/lib/python2.7/site-packages/dose/watcher.py", line 34, in watcher
    observer.start()
  [...]
  File "/usr/lib/python2.7/site-packages/watchdog/observers/inotify_c.py", line 402, in _raise_error
    raise OSError("inotify watch limit reached")
OSError: inotify watch limit reached

A really simple way to get an OSError is to run Dose on /:

$ cd /
$ dose echo -n
                 *** First call ***
====================================================
         [Dose] 2016-11-27 04:10:53.223946
====================================================
Traceback (most recent call last):
  [...]
  File "/usr/lib/python2.7/site-packages/dose/_legacy.py", line 487, in start
    self._watcher.__enter__() # Returns a started watchdog.observers.Observer
  File "/usr/lib/python2.7/contextlib.py", line 17, in __enter__
    return self.gen.next()
  File "/usr/lib/python2.7/site-packages/dose/watcher.py", line 34, in watcher
    observer.start()
  [...]
  File "/usr/lib/python2.7/site-packages/watchdog/observers/inotify_c.py", line 406, in _raise_error
    raise OSError(os.strerror(err))
OSError: Permission denied

The above errors happened on Dose 1.2.0 using watchdog 0.8.3. Though watchdog should switch to polling (like tail -F does) instead of crashing, Dose still has to handle exceptions coming from watchdog.

This is a proposal for new features in Dose.

Choosing the wxPython version

Since Dose is compatible with wxPython Classic 2.8, wxPython Classic 3.0 and wxPython Phoenix, I was thinking on a way to let the user choose the visual interface when he/she has more than one wxPython Classic installed (using the wxversion package). That doesn't make much sense on wxPython Phoenix (where wxversion doesn't exist anymore), but on wxPython it would be nice to allow a command line option to choose between wxPython 2.8 and 3.0 when both are installed. Using the idea on #6, it could be done as:

dose --wx 2.8
dose --wx 3.0 # Classic
dose --wx default # including wxPython Phoenix

By default, Dose would be called with --wx default. That should be the way Dose is running by now. The other options would call wxversion.select before running Dose, and it should work with any parameter that function accepts (besides default).

Dose without wxPython

Nothing stops Dose from having multiple interfaces implemented. I was thinking on this feature when the dose.compat.wx object was written: this object should allow importing wx without actually needing wx.

Perhaps it would be better to avoid the --wx default, and break the --wx in 2 parameters:

dose --ui wx --wxversion 3.0

For now, only the wx UI exists, but other user interfaces (e.g. tk, gtk, curses) might exist in the future. The --wxversion would only exist when wxPython classic is installed (e.g., when the wxversion module can be imported).

Dose without a GUI (CLI Dose)

Some people might want to use Dose with its resources (the watcher and runner) completely without a GUI. It's related to the enhancement proposal #7, as a CLI version of Dose would be easier to run in a docker container with something like docker run -it --rm -v "$(pwd)":/src some_image_with_dose test_job_command.

Dose can be enhanced to be a CLI-only application (without removing its GUI capabilities) in at least 3 different ways:

• Including a --nogui option or a --ui none, which would behave like it does today when called with trailing arguments as the test job command, but without any GUI;
• Including a --cli option or a --ui cli, which would show a formatted and colored ASCII traffic light at the end of a test job. There would be only 2 colors in this traffic light, as the "Yellow" step wouldn't ever happen. In a second version of such an interface, it could allow a getch-like input to customize the traffic light (perhaps even disabling it, something that would deprecate the --ui none);
• Including a --curses option or a --ui curses for a ncurses CLI interface for Dose, with a full ASCII traffic light (if possible).

Issue #6 brought cli-args support to dose using click. Consider the following - currently accepted with a deprecation warning - dose call:

dose tox --help

How can we securely tell that everything after tox is supposed to be treated as arguments instead of dose options? Let's change this call a little:

dose --cli tox --help
dose --no-cli tox --help

What should happen? "--no-cli" is a switch option, but "--cli" receives a parameter. So, heuristically, we would assume that dose should be called using "tox" cli and display help text in the first case, but run headless the command "tox --help" in the second. One may argue that this doesn't sound quite right.

The proposal is to deprecate this call style (dropping it at the next major release), in favor of forcing the user to double-dash arguments (the test_command) from options:

dose --cli -- tox --help (will cause an error, like we would expect as an user)
dose --no-cli -- tox --help

The double-dash allow us to be more precise and less error-prone when calling dose.

Note that this issue is starting as a discussion. There's no assumption that this line of thought is the way to go.

Man, instalei via PIP o dose, já com wx e watchdog e quando executei ele me cuspiu isso:

Traceback (most recent call last):
File "/usr/local/bin/dose.py", line 89, in
class DoseGraphicalSemaphore(wx.Frame):
AttributeError: 'module' object has no attribute 'Frame'

Colors are something that can be easily modified in the Dose code. The most difficult part is to create a good interface for it. This issue is a plan for customizing features that future versions of Dose may have.

Config dialog unification

Dose may have one Preferences... menu option, that includes the GUI flip bit as a check box and the ignore pattern as a text/edit box, replacing the two related menu options.

Console standard error coloring

The new modal dialog box for the preferences customization should include a way to enable/disable the "red" color applied to the test job standard error on logging it to the terminal.

Color customization

Dose uses only a few colors regarding both console colors and GUI colors, and some may have a way to be changed by the user (e.g. the 3 GUI "LED" colors, the GUI background and the standard error color).

Hello, @danilobellini , how are you?

I read this blog post Running GUI apps with Docker and got wondering if it could help making this project more used nowadays!

I don't know if you remember that times when we went often to Coding Dojos here in São Paulo, and I already was a big fan of Vagrant. Because of this, I tried to keep all dojo environments inside a Vagrantfile, but I couldn't put dose for work with that setup (as dose is a GUI program, and Vagrant by default only manage cli and service things).

I remember you saying something about connecting "X" of guest to the host order to make it works however I think you never finished that "dream" ;-)

I think this blog post above could be that start! It could be used for Vagrant, Docker or anything related I guess. What do you say?

See ya!

See the following image for reference:

Note that yellow/cyan control characters are being translated just as expected.

Is there a way to turn off dose colors?

Currently, when I run dose at ubuntu it displays everything red even when the tests are passing:

So I tried to run my test command with rednose but even running with it dose overrides it.

The command that I tried was:

dose nosetests --rednose tests.py

Today, dose.py has a GUI configuration as well as a CLI command-line approach that allows a fast call like dose tox -v or dose "cat my_code.lang | my_interpreter.sh" and many things alike. However, parameters like the -v in that example are for the given command, not for dose, i.e., that means dose "tox -v".

A solution for giving CLI arguments for dose.py would be allowing them to happen BEFORE the command, which would be known based on the char "-" and from the context, e.g. dose.py --config dose.conf tox -v would mean:

• Call dose.py directly and auto-start (because a command is given)
• The call command is tox -v
• Configuration file is dose.conf (where $HOME/.dose.conf would still be a fallback for "defaults" not explicitly written in the given alternative, though it should be kept unchanged).

This issue is to add the first CLI arguments for dose.py, allowing:

• -h or --help for help
• --config=CONFIG for setting up a specific configuration file (or directory, meaning a .dose.conf should be created there)
• --size=SIZE for setting a initial window size like 200x200 (fractals CLI would help)
• --position=POSITION, parsed like the size
• --opacity=OPACITY, a value from 0 (transparent) to 255 (opaque)
• --flip and --noflip to ensure whether image flipping should be done

So the configuration should have the following priority levels (for reading):

1. CLI arguments
2. Local config file, passed as --config or as a ./.dose.conf file
3. User config file $HOME/.dose.conf
4. Global defaults as "hardcoded" in dose.py

The following command won't work on Windows:

dose dir "C:\Program Files"

I've tested it in Windows 10 x64, using the current master branch (v1.2.0).

The problem resides in the main module, inside the main function. The (un)quoting process ends up producing this command line, which the Command Prompt can't understand:

dir 'C:\Program Files'

The error message is the same as the one output by dose if I try to execute it directly in cmd.exe, as expected. Here it is for reference:

The filename, directory name, or volume label syntax is incorrect.

I don't like the way the "file pattern glob" is used today in dose.

There's already one common file to store a list of ignoring patterns: .gitignore. One can get several examples here.

Why not use the same idea to decide whether a file change should be neglect in dose?

But one can also think on a reversed approach: why not watch files only when they're at least staged on git? Explicitly, only a file in git ls-files would be watched.

...and a Mercurial user wouldn't be happy either. For the ignored file, dose would be changed to ignore watching files that matches both .gitignore and .hgignore contents, if any, without defaults. Obviously, these files can be changed on the fly as well, and such a change would change the whole filtering going on.

For now, this issue is still an open question about how the "file pattern glob" configuration should be changed to be better. How should we configure dose to allow (without bureaucracy, i.e., "convention over configuration" + DRY):

1. Neglecting all but a few globs/patterns/regexes
2. Ignoring none but some few globs/patterns/regexes
3. Having useful defaults (e.g. ignore the .git directory as usually no one changes its contents manually; use the .gitignore and .hgignore files)
4. Performing some inference about whether a file change means something or not without "losing control" of what is being done

As suggested by previous dojos participants, it would be nice to have a Pomodoro like component built in dose.

I'm creating this issue to improve the requirements of the feature, before any coding. Following is my understanding as a starting point:

• Add a timer positioned aside the semaphore;
• Add a play/pause and a reset button (without the need to right click);
• Add a "Timer duration" option inside the right click menu, allowing to change the default value (7 minutes).