I have a complex chain of tasks that I don't want to be all exposed/available when using pynt.

I can use internal python functions instead, but I really like the simplicity of chaining tasks and having consistent logs etc...

Adding @task(hide=True) might be a nice addition

So it looks something like that: @task(hide=True) def build(): '''Build for distribution'''

@task(hide=True) def upload(): '''Upload build'''

@task(hide=True) def install(): '''Install new build distribution'''

@task() def restart_server: ''Restart the server'''

@task(build, upload, install, restart_server) def deploy_prod(): '''Build & deploy app to production server. Then restart server.''' print("Deployment Complete!")

At the moment, they are all exposed as tasks, and can appear in pynt output: Tasks in build file build.py: build Build for distribution clean Clean build directory. deploy_prod Build & deploy app to production server. Then restarts server. install Install new build distribution'' restart_server Restart pserve on remote upload Upload the latest build to server

Would you like any of these functions? If so, I can submit them as a pull request (with tests).

https://github.com/WimpyAnalytics/pynt-of-django/blob/master/pyntofdjango/utils.py

I would like to use pynt for a Java project. The caller task looks like this:

@task()
def run():
    cmd = "java -cp build/classes/java/main adder.Adder"
    print(cmd)
    os.system(cmd)

Let's suppose that we can pass command-line arguments to the Java program:

bash$ java -cp build/classes/java/main adder.Adder 5 6
11

and it adds them together. Would it be possible to pass these arguments to a task and then forward them to the Java program? I want a call like this:

bash$ pynt run 5 6
11

At the moment pynt thinks that "5" is another task and drops an error that it doesn't exist.

If @task(hide=True) is set, the given task won't appear in the auto-generated docs. It's useful if you want to hide sub-tasks and you only want to see the main tasks in the generated list.

It would be a good idea to add your build tool to this list: https://en.wikipedia.org/wiki/List_of_build_automation_software . SCons is there, another build tool written in Python.

I also want to say thanks for this project! It's perfect for my needs.

pynt -h produces: C:\Users\Bruce>pynt -h usage: pynt-script.py [-h] [-l] [-f file] [task [task ...]]

positional arguments: task perform specified task and all it's dependancies ...

On the last line shown above, the "it's" should be "its" and "dependancies" should be "dependencies"

I can't tell if I'm missing where the documentation is, or if the page (http://rags.github.io/pynt/) is supposed to be the documentation. If the latter, there's a line:

"Tasks can be ignored with the task(ignore=True)"

I can't figure out what this means.

I like the design, BTW. Very clean.

Several places in the help you say "it's" which means "it is" when you actually want to use a possessive "its"

The easiest way to test this is when you see an "it's", say it out loud "it is," and see if that makes sense. If it doesn't, remove the apostrophe.

Instead of @task(hide=True), simply rename your task. If the name of the task starts with an underscore, then it's a hidden task, thus it won't appear in the auto-generated docs.

Hi, I really like pynt and would like to use it as a build tool for some of my python projects. My builds are already using docker to allow me to create a container, install my dependencies and then run the tests. To use pynt as a build system I need to install it outside the container on the build server. Do you have any ideas on the easiest way to do that (assuming I can't just pip install things on the build server)?

Hi,

Sometimes the task name matching feature can be a dangerous thing and one might only want to allow exactly matching task names as arguments.

This merge request introduces the ability to add the statement __TASK_NAME_RESOLVER__ = 'strict' to the build file to tell pynt to only accept fully matching task names.

Unit tests have been updated.

Thanks, Torben

Is there any interest in the community for a Markdown output from the @task() docstrings? If so, I can submit a PR.

In my project, I adopted the standard of:

@task()
def start_server(server='localhost', port = '80'):
    """Start the server

    This task starts the HTTP server on localhost:80 (by default)

    - Args:
        - `server` (`str`, optional): The server IP address. Defaults to 'localhost'.
        - `port` (`str`, optional): The port number. Defaults to '80'.
    """

    print('Starting server at %s:%s' % (server, port))

@task(start_server) #Depends on task with all optional params
def stop_server():
    """Stop the server

    This task stops the running server
    """
    print('Stopping server....')

This would create the following output:

$ pynt -l -m

Raw

---
## start_server

`Start the server`

This task starts the HTTP server on localhost:80 (by default)

- Args:
    - `server` (`str`, optional): The server IP address. Defaults to 'localhost'.
    - `port` (`str`, optional): The port number. Defaults to '80'.

---
## stop_server

`Stop the server`

This task stops the running server

Formatted:

start_server

Start the server

This task starts the HTTP server on localhost:80 (by default)

• Args:
  • server (str, optional): The server IP address. Defaults to 'localhost'.
  • port (str, optional): The port number. Defaults to '80'.

stop_server

Stop the server

This task stops the running server

It happens because of this:

https://github.com/rags/pynt/blob/c0fbbc4c0c6c1ccbbf11a744fb62d33c78ac0ae0/build.py#L18

In my system, I have both Python 2 and 3 (maybe it's worth dropping Python 2 support already?). Executables are named py.test and py.test3.

To maintain backwards compatibility, it's probably worth wrapping those subprocess calls and if they fail - try generic names.

Use case: I have a main task that performs actions on items of an iterable, so instead of specifying the one-item task as dependency, I call it directly. Here's my code:

#!/usr/bin/env python3

from pynt import task

ITEMS = ["foo", "bar"]


@task()
def item_task(item):
    print(item)


@task()
def main_task():
    for item in ITEMS:
        item_task(item)


__DEFAULT__ = main_task

This is the output I'm getting:

[ build.py - Starting task "main_task" ]
foo
bar
[ build.py - Completed task "main_task" ]

Since item_task() is a task too, I'd prefer the following output:

[ build.py - Starting task "main_task" ]
[ build.py - Starting task "item_task" with argument "foo"]
foo
[ build.py - Completed task "item_task" ]
[ build.py - Starting task "item_task" with argument "bar"]
bar
[ build.py - Completed task "item_task" ]
[ build.py - Completed task "main_task" ]

Maybe even with nested tasks indented:

[ build.py - Starting task "main_task" ]
    [ build.py - Starting task "item_task" with argument "foo"]
    foo
    [ build.py - Completed task "item_task" ]
    [ build.py - Starting task "item_task" with argument "bar"]
    bar
    [ build.py - Completed task "item_task" ]
[ build.py - Completed task "main_task" ]

The directory of the build script is not part of Python's import path inside the pynt process, hence it is not possible to import modules which reside beneath the same directory as the module.

It can be solved by amending the Path with the directory of the build script.