Рабочий процесс для поддержки различных версий кода для разных версий Python

Question

Я разрабатываю приложение с открытым исходным кодом под названием GarlicSim.

До сих пор я разрабатывал его только для Python 2.6. Кажется, что он не работает ни на одной другой версии.

Я решил, что важно создавать версии, которые будут поддерживать другие версии Python. Я думаю, что я сделаю версию для 2.5, 3.1 и, возможно, 2.4.

Так у меня есть несколько вопросов:

1. Что бы хороший способ организовать структуру папок моего репозитория, чтобы включить эти разные версии?
2. Что было бы хорошим способом «слияния» изменений, которые я делаю в одной версии кода для других версий? Я знаю, как делать слияния в моем SCM (это git), но это папки, которые находятся в одном и том же репо, и я хочу сделать слияние между ними. Конечно, есть возможность иметь репо для каждой версии, но я думаю, что это не очень хорошая идея.

Есть ли у кого-нибудь предложения?

Answer 1

я бы попытаться сохранить одну ветвь, чтобы охватить все питон 2,4-2,6

различия не столь велики, в конце концов, если вы должны написать кучу дополнительного кода для 2.4, чтобы сделать что-то, что легко в версии 2.6, для вас в конечном итоге будет меньше работать, чтобы использовать версию 2.4 для версий 2.5 и 2.6.

Python 3 должен иметь другую ветку, вы все равно должны стараться хранить как можно больше кода.

Answer 2

Если ваш код не слишком зависит от производительности во время выполнения в обработчиках исключений, вы даже можете уйти без отдельной ветви для Py3. Мне удалось сохранить одну версию pyparsing для всех моих версий Py2.x, хотя мне пришлось придерживаться подхода «самый низкий общий знаменатель», что означает, что я должен отказаться от использования некоторых конструкций, таких как выражения генератора, и вашей точки, менеджеров контекста. Я использую dicts вместо наборов, и все мои выражения генератора становятся обернутыми как списки, поэтому они все равно будут работать, возвращаясь к Python 2.3. У меня есть блок в верхней части моего кода, который берет на себя ряд вопросов, 2vs3 (пополняемая Pyparsing пользователя Robert A Clark):

_PY3K = sys.version_info[0] > 2 
if _PY3K: 
    _MAX_INT = sys.maxsize 
    basestring = str 
    unichr = chr 
    unicode = str 
    _str2dict = set 
    alphas = string.ascii_lowercase + string.ascii_uppercase 
else: 
    _MAX_INT = sys.maxint 
    range = xrange 
    def _str2dict(strg): 
     return dict([(c,0) for c in strg]) 
    alphas = string.lowercase + string.uppercase 

Самая большая трудность у меня было уже с несовместимым синтаксисом перехват исключений, который был введен в PY3, меняясь от

except exceptiontype,varname: 

в

except exceptionType as varname: 

конечно, если вы на самом деле не нужна переменная исключения, вы можете просто написать:

except exceptionType: 

, и это будет работать на Py2 или Py3. Но если вам нужно получить доступ исключения, вы можете прийти с кросс-версия, совместимым синтаксисом, как:

except exceptionType: 
    exceptionvar = sys.exc_info()[1] 

Это незначительное время выполнения пенальти, который делает это непригодным для использования в некоторых местах в Pyparsing, так Я все еще должен поддерживать отдельные версии Py2 и Py3.Для слияния источника я использую утилиту WinMerge, которую я нахожу очень хорошо для синхронизации каталогов исходного кода.

Таким образом, хотя я сохраняю две версии моего кода, некоторые из этих методов унификации помогают мне сохранить различия до абсолютного несовместимого минимума.

Answer 3

Вам нужны отдельные ветви для отдельных версий только в самых редких случаях. Вы упоминаете менеджеров контекста, и они прекрасны, и это сосать, чтобы не использовать их, и вы правы. Но для Python 2.4 вам не придется их использовать. Так что сосать. Поэтому, если вы хотите поддерживать Python 2.4, вам придется писать версию без контекстных менеджеров. Но это тоже будет работать под Python 2.6, поэтому нет смысла иметь отдельные версии там.

Что касается Python 3, имеющего отдельную ветвь, есть решение, но, как правило, не самое лучшее. Для поддержки Python 3 есть что-то, называемое 2to3, которое преобразует ваш код Python 2 в код Python 3. Это не идеально, поэтому довольно часто вам придется модифицировать код Python 2 для создания красивого кода Python 3, но код Python 2 имеет тенденцию к лучшему в результате в любом случае.

С помощью Distribute (поддерживаемой вилки setuptools) вы можете сделать эту беседу автоматически во время установки. Таким образом, вы не должны иметь отдельную ветвь даже для Python 3. См. http://bitbucket.org/tarek/distribute/src/tip/docs/python3.txt для документации по этому вопросу.

Как пишет Пол МакГир, возможно даже поддерживать Python 3 и Python 2 с тем же кодом без использования 2to3, но я бы не рекомендовал его, если вы хотите поддерживать что-либо еще, кроме 2.6 и 3.x. Вы получаете слишком много этих уродливых специальных хаков. В версии 2.6 есть достаточно передовой совместимости с Python 3, чтобы можно было писать достойный код и поддерживать как Python 2.6, так и 3.x, но не Python 2.5 и 3.x.

Answer 4

В итоге я решил иметь 4 разных вилки для моего проекта, для 2.4, 2.5, 2.6 и 3.1. Мой главный приоритет - 2,6, и я не хочу компрометировать элегантность этого кода ради 2.4. Таким образом, уродливые взломы совместимости будут на более низких версиях, а не на более высоких версиях.