Неправильный подход к размещению версии в имени пакета?

Question

Я работаю с программным обеспечением, в котором есть встроенная среда Python, в которой не доступны все стандартные модули Python.Например, нет pip или pkg_resources.Единственный способ добавить сторонние модули / пакеты - это скопировать их в путь, указанный в sys.path.

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

Теперь на мой вопрос.Считается ли плохим подход иметь номер версии внутри имени пакета или полностью как подпакет?Например, mypackage_0_1/ или mypackage/0_1/

Если это так, что может быть хорошей альтернативой для решения этой проблемы?

Answer 1

В большинстве случаев номер версии в пакете, независимо от языка, используется для передачи информации о совместимости. Например, Qt: есть серии Qt4 и Qt5. Цифры означают, что у нас разные API, и переключение с Qt4 на Qt5 в основном сломает ваше приложение. Аналогично, Python следует этой схеме: у вас есть серии Python 2.x и 3.x. Это означает, что если вы пишете свое приложение для Python 3.6, ожидается, что оно будет работать с Python 3.7. Другими словами, выпуски Python 3.x совместимы напрямую (т. Е. Ожидается, что программное обеспечение, написанное для более старой версии Python 3.x, будет работать нормально с более новыми версиями). Однако, написание вашего приложения для Python 2.7 и запуск его, например, в Python 3.7, в основном принесут неожиданные результаты. Следовательно, Python 3.x нарушает совместимость с Python 2.x, и они не имеют обратной совместимости.

Поэтому я советую придерживаться этого правила: используйте номер версии только в имени пакета и только в том случае, если вы сообщаете, что создаете серию совместимых с прямой версией вашего пакета.