Runscript — утилита для запуска python скриптов

[hardex]

Псст, парень,

if __name__ == '__main__':

Только никому!

[itforge]

Не понял.

[Rivethead]

Имелось в виду, что это условие позволяет запускать скрипт без дополнительных приблуд:
как-то так

[itforge]

Это условие

if __name__ == '__main__':
    main()

позволяет как раз *не* запускать фунцию main(), в том случае, если мы импортировали модуль скрипта в другом модуле. Именно эту проблему, решает вышеприведённое условие.

Чтобы запустить на выполнение фунцию main, достаточно её запустить :)) Без всяких условий.

main()

[ErhoSen]

Как это решает проблему, описанную выше?

├── program.py
└── scripts
    └── script.py

program.py:

def hello_world():
    print "Hello, world!"

scripts/script.py:

import program

def actions():
    program.hello_world()

actions()

[splav_asv]

Видимо, проблема настолько не очевидна, что многие, включая меня, вообще никакой проблемы не видят.
Может я что-то не понимаю?
В чем собственно проблема выполнить скрипт на питоне?

[ErhoSen]

Если прописать python scripts/script.py вылетит ImportError, говорящий что нету модуля program в пределе досягаемости. Если я правильно понял, автор решает именно этот кейс.

Так вот я и спросил, как

if __name__ == '__main__':

Решает эту проблему.

[splav_asv]

python -m scripts/script.py?

[splav_asv]

Тфу, python -m scripts.script

[ErhoSen]

Действительно, нужно просто упаковать скрипт в пакет.
Не знал, что так можно. Спасибо!

[splav_asv]

По сути ключ -m добавляет текущую директорию в sys.path

[itforge]

Для меня это ничего не меняет. У меня есть альтернатива:

Вариант 1:

def main():
    pass

if __name__ == '__main__':
    main()

$ python -m script.preved

Вариант 2:

def main(**kwargs):
    pass

$ run preved

Я выбираю вариант 2 — нужно меньше букв печатать, как в скриптах, так и в консоли. Для меня это важно. И мне очень приятно, что я экономлю это время. Как я уже заметил в статье, ничего революционного пакет runscript не делает, но то малое, что он делает, очень удобно.

Кроме, краткости, вариант 2 предоставляет упрощённую обработку аргументов командной строки и другие плюшки, о которых я написал в статье.

Я просто поделился тем, как запускаю скрипты в своих проектах. Никому ничего не навязываю и не говорю, что мой способ самый «лучший» (что бы это ни значило).

[Shoonoise]

> Я выбираю вариант 2
Это «неправильный» выбор. Если вы планируете запускать скрипт из консоли, то надо писать

if __name__ == "__main__":

хотя бы потому, что

$ python -m script.preved

не требует установки пакета для работы.

Исключение — вы пишете код для себя и никто никогда не будет с ним работать и запускаться он будет на одной машине.

[itforge]

Очень часто пишу код именно для себя. Если мы говорим о каком-то проекте, где работает несколько людей, то тоже не вижу особенной проблемы. Обычно проект это virtualenv + requirements.txt, при разворачивании проекта на новой машине, все зависимости, и в том числе, runscript, поставятся автоматом.

Я, честно, плохо понимаю, зачем каждый раз писать «python -m package.module» в вашем проекте для запуска скриптов, если можно договориться написать какой-то запускальщик, который будет решать рутинные операции, специфичные для большинства скриптов этого проекта. В роли запускальщика может выступить в том числе и runscript.

[muslimov]

Вы знаете несколько минусов:
1. Взять docopt и сделать так, чтобы он делал импорт нужного модуля и вызов main. Весьма просто, и дело одного абзаца
2. Если у вас уже есть django — то там есть стандартные commands с интерфейсом argparse. Зачем еще runscript?
3. lock-file это наверно хорошая штука если у вас только 1 сервер, который выполняет этот код. Например, если на уровне кода нет разделения, то любой девелоперская машина выполнит тот же код что и на проде — итог, очень просто выстрелить себе в ногу.

[itforge]

1. Про decopt не понял, не использовал этот пакет. Можно подробнее?

2. Во-первых, django я не в каждом проекте использую. Во-вторых, мне не нравятся django management commands. Мне нравится писать простые скрипты с одной функцией и складывать их в одну директорию в проекте. В случае джанго нужно запрятать скрипты подальше — в management/commands каталог какого-либо приложения. Да и сами скрипты становятся сложнее. Сравните:

django

from django.core.management.base import BaseCommand
from optparse import make_option


class Command(BaseCommand):
    option_list = BaseCommand.option_list + (
        make_option('-w', '--who'),
    )

    def handle(self, who, *args, **options):
        print(who)

runscript

def setup_arg_parser(parser):
    parser.add_argument('-w', '--who')

def main(who, **kwargs):
    print(who)

3. Не очень понял, что вы имели в виду. Можно пример выстрела?

[muslimov]

Ok,

1. Вот github.com/docopt/docopt, предлагается просто завести первым аргументом, что-то и делать согласно ему import_module().main(args).

2. Ну так ок, это не так сложно вроде в папку commands бросить файл, синтаксис я бы не сказал что невыносимый. Только еще плюсом идет факт, что там стоит немаленького размера optparse, котором намного больше функций, чем runscript.add_argument.

3. Я имел что lock-file работает только на одной машине, у другого сервера lock-file нет и следовательно ваш механизм блокировки не работает.

[itforge]

1. Если я вас правильно понял, я это и делаю, только без docopt :)

2. По поводу optparse вы наверное не совсем поняли меня. Дело в том, что runscript тоже использует optparse, вернее даже не optparse, а argpase. Я в статье писал про это. Сложно или не сложно вам создать файл, кажется ли вам синтаксис django management commands выносимым или нет, я не обсуждаю. Это ваше личное дело. Я просто рассказал, что лично я думаю о django management commands. Вообще этот пункт особо не имеет смысла обсуждать т.к. я использую джангу не во всех проектах, я чуть выше уже говорил об этом.

3. Да, блокировка через lock-файл работает только в пределах одной машины. Меня это устраивает. Фунциональность runscript — это решение моих задач. Задачи лочить выполнение скриптов сразу на нескольких машинах у меня не воникало.

[muslimov]

1. да
2. используйте docopt или click (http://click.pocoo.org/3/)
3. да

Ну мы говорим не только о Вас, а о нас программистах в целом.

[itforge]

2. На данный момент меня вполне удовлетворяет argparse, идущий в stdlib питона.

Я всё же скорее про себя говорю. Мол были такие-то задачи, я их так-то решил. Это конкретный разговор. О программистах в целом мне рассуждать не интересно. У каждого свои проблемы и каждый решает их по разному. Если кому-то понравится идея runscript, он может использовать эту библиотеку. Если кто-то считает, что она стреляет в ногу или не делает ничего полезного, он не будет её использовать

[muslimov]

> Если кому-то понравится идея runscript, он может использовать эту библиотеку

Хей, да в чем идея то? Я же Вам привожу и привожу ссылки, а Вам неинтересно рассуждать о программистах в целом. Экий, Вы не уловимый Джо.

[itforge]

Извините, я не понимаю, что вы хотите сказать.

[k0t]

В django_extensions есть команда runscript

[Yur4eg]

Однажды я взял и потратил день на изучение virtualenv и setuptools. С тех пор на тех кто манипулирует sys.path я смотрю свысока

[itforge]

Держите нас в курсе, на кого вы смотрите свысока :)

[gecube]

TL;DR.
Вопрос в чем — в случае падения python-скрипта lock-файл автоматически удалится? Если нет, то это баг, т.к. это блокирует последующие выполнения.