как установить setup py linux

unixforum.org

Форум для пользователей UNIX-подобных систем

Модератор: Bizdelnick

Сообщение NK » 07.02.2009 07:41

PS пробовал набивать

Сообщение Lenux » 07.02.2009 09:25

Сообщение arkhnchul » 07.02.2009 12:25

Сообщение NK » 07.02.2009 18:57

Сообщение anjolio » 07.02.2009 19:21

Сообщение NK » 07.02.2009 19:30

Аах-Да-Да, спасибо, действительно в тему для новичков)

Сообщение arkhnchul » 08.02.2009 12:42

Сообщение NK » 08.02.2009 19:04

Спасибо,
пробую, но пока что результат неутешительный(

Сообщение arkhnchul » 08.02.2009 19:36

Сообщение NK » 08.02.2009 21:03

Сейчас, вот попробовал по-новой, а то что-то предположение появилось, что может напутал с каталогом и с самой сборкой,

Источник

Что setup.py?

может кто-нибудь объяснить, что такое setup.py и как его можно настроить или использовать?

10 ответов

Это позволяет легко устанавливать пакеты Python. Часто достаточно написать:

и модуль установит себя.

это помогает установить пакет python foo на вашей машине (также может быть в virtualenv ), так что вы можете импортировать пакет foo из других проектов, а также из подсказок [I]Python.

используя setup.py

давайте начнем с некоторых определений:

некоторые пакеты являются чистым Python и компилируются только байтами. Другие могут содержать собственный код, для которого потребуется собственный компилятор (например, gcc или cl ) и модуль сопряжения Python (например, swig или pyrex ).

Если вы загрузили пакет, который имеет «setup.py» в корневой папке вы можете установить его, запустив

Если вы разрабатываете проект и Вам интересно, для чего этот файл полезен, проверьте документация Python по написанию сценария установки

при загрузке пакета с setup.py откройте терминал (Mac, Linux) или командную строку (Windows). Используя cd и помогая вам с помощью кнопки Tab установить путь прямо к папке, где вы загрузили файл и где есть setup.py :

нажмите enter, вы должны увидеть что-то вроде этого:

затем введите после этого python setup.py install :

чтобы установить загруженный пакет Python, вы извлекаете архив и запускаете setup.py скрипт внутри:

мне это всегда казалось странным. Было бы более естественно указать менеджер пакетов на загрузку, как это было бы в Ruby и Nodejs, например. gem install rails-4.1.1.gem

менеджер пакетов также более удобен, потому что он знаком и надежен. С другой стороны, каждый setup.py является новым, потому что он специфичен для пакета. Она требует веры в конвенция «я доверяю этому setup.py принимает те же команды, что и другие, которые я использовал в прошлом». Это прискорбный налог на умственную силу воли.

Я не говорю, что setup.py рабочий процесс менее безопасен, чем менеджер пакетов (я понимаю, что Pip просто запускает setup.py внутри), но, конечно, я чувствую, что это неловко и неприятно. Существует гармония в командах, которые все находятся в одном приложении диспетчера пакетов. Вы даже можете полюбить его.

чтобы сделать его простым, setup.py выполняется как «__main__» когда вы называете установить функции другие ответы упомянули. Внутри setup.py, вы должны поставить все необходимое для установки пакета.

общие setup.py функции

в следующих двух разделах обсуждаются две вещи setup.py модули есть.

setuptools.setup

эта функция позволяет указать атрибуты как имя проект, версия. Самое главное, эта функция позволяет устанавливать другие функции, если они упакованы правильно. См.этот сайт для примера setuptools.установка

Эти атрибуты setuptools.настройка включить установку этих типов пакетов:

пакеты, импортированные в ваш проект и перечисленные в PyPI используя setuptools.findpackages:

packages=find_packages (exclude=[«docs», «tests»,».gitignore», » README.первое», » описание.первый»])

пакеты не в PyPI, но можно загрузить с URL-адреса с помощью dependency_links

пользовательские функции

в идеальном мире, setuptools.setup будет обрабатывать все для вас. К сожалению, это не всегда так. Иногда вам нужно делать определенные вещи, такие как установка зависимостей с помощью подпроцесс команда, чтобы получить систему, которую вы устанавливаете в правильном состоянии для вашего пакета. Постарайтесь избежать этого, эти функции запутываются и часто отличаются между OS и даже распределение.

setup.py есть файл Python, как и любой другой. Он может принимать любое имя, кроме условного, он называется setup.py чтобы не было другой процедуры с каждым скриптом.

чаще всего setup.py используется для установки модуля Python, но сервер других целей:

модули:

этот метод часто используется, когда pip не удастся. Например, если правильная версия Python желаемая пакет не доступен через pip возможно, потому, что он больше не поддерживается, загрузка источника и запуск python setup.py install выполнит то же самое, за исключением случаев, когда требуются скомпилированные двоичные файлы (но будет игнорировать версию Python-если не будет возвращена ошибка).

другое использование setup.py установить пакет из исходников. Если модуль все еще находится в разработке, файлы wheel будут недоступны, и единственный способ установить-установить из источника непосредственно.

создание расширений Python:

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

сценарий установки легко построить, и как только файл был правильно настроен и может быть скомпилирован путем запуска python setup.py build (см. ссылку для всех команд).

еще раз он называется setup.py для простоты использования и по соглашению, но может принимать любое имя.

на Cython:

еще одно знаменитое использование setup.py файлы скомпилированных расширений. Для этого требуется сценарий установки с пользовательскими значениями. Они позволяют быстро (но после компиляции зависят от платформы) выполнять. Вот простой пример из документация:

это можно скомпилировать через python setup.py build

Cx_Freeze:

что это setup.py файл?

просто это скрипт, который создает или настраивает что-то в среде Python.

пакет при распространении должен содержать только один сценарий установки, но это не редкость, чтобы объединить несколько вместе в один сценарий установки. Обратите внимание, что это часто включает distutils но не всегда (как я показал в моем последнем примере). Вещь, чтобы помнить, что она просто настраивает пакет/скрипт Python каким-то образом.

он принимает имя так одна и та же команда всегда может быть использована при построении или установке.

Источник

linux-notes.org

В этой статье «Установка pip/setuptools/wheel в Unix/Linux» описывается, как установить pip, setuptools и wheel в Unix/Linux ОС.

Установка pip/setuptools/wheel в Unix/Linux

Приведу установку на различные Unix/Linux ОС.

Установка pip/setuptools/wheel в Fedora

Чтобы установить Python 2 на Fedora 21, используйте следующие команды.

Для начала обновим тулзы:

Чтобы установить Python 3 на Fedora 21, используйте следующие команды:

Чтобы установить Python 2 на Fedora 22, используйте следующие команды.

Для начала обновим тулзы:

Чтобы установить Python 3 на Fedora 22, используйте следующие команды:

Чтобы получить новые версии pip, setuptools и wheel для Python 2, вы можете включить PyPA Copr репозиторий:

И после чего, выполнить:

Установка pip/setuptools/wheel в CentOS/RHEL

Чтобы установить pip и wheel, существует два варианта:

1. Включите репозиторий EPEL, используя эти инструкции:

После чего, вы можете установить pip следующим образом:

На EPEL 7 (но не EPEL 6), вы можете установить wheel следующим образом:

2. Включите репозиторий PyPA Copr репозиторий:

После чего, вы можете установить pip следующим образом:

Чтобы обновить setuptools, запустите:

Чтобы установить Python 3.4 на CentOS7/RHEL7, используйте:

Установка pip/setuptools/wheel в openSUSE

Чтобы установить Python 2:

Чтобы установить Python 3:

Установка pip/setuptools/wheel в Debian/Ubuntu

Чтобы установить Python:

Чтобы установить Python 3:

Установка pip/setuptools/wheel в Arch Linux

Чтобы установить Python 2:

Чтобы установить Python 3:

Установка pip/setuptools/wheel в Mac OS X

Добавляем HOMEBREW на Mac OS X ( устанавливаем его):

После чего, можно приступать к установке:

Или, чтобы установить python 3:

Установка pip/setuptools/wheel с исходного кода.

И, чтобы получить самое новое ПО, НЕОБХОДИМО КОМПИЛИРОВАТЬ ЕГО!

Установка pip/wheel с исходного кода

Очень простая установка:

Установка setuptools с исходного кода

Смотрим где лежит нужный питон (у меня это 3.4):

И выполняем сборку:

ИЛИ, все в одной строке:

Установка easy_install с исходного кода

easy_install позволяет установить pip и его компоненты.

Смотрим где лежит нужный питон (у меня это 3.4):

И выполняем сборку:

Использование PIP

Поиск пакета Python с помощью команды pip:

Установка пакета с помощью команды pip:

Список пакетов Python, которые уже установлены в системе, можно проверить с помощью команды pip:

Показать информацию о пакете Python:

Вот полезное чтиво:

А на этом, у меня все. Тема «Установка pip/setuptools/wheel в Unix/Linux» завершена.

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Источник

setup.py

Введение

Примеры

Назначение setup.py

Если все, что вам нужно, это распространить модуль с именем foo, содержащийся в файле foo.py, то ваш скрипт установки может быть таким простым:

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

Добавление сценариев командной строки в ваш пакет Python

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

Вы можете запустить этот скрипт, запустив:

Однако, если вы хотите запустить его так:

При установке пакета приветствия теперь hello_world.py будет добавлен к вашему пути.

Другой возможностью было бы добавить точку входа:

Таким образом, вы просто должны запустить его так:

Использование метаданных контроля версий в setup.py

Добавление параметров установки

Как видно из предыдущих примеров, основное использование этого скрипта:

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

После этого вы сможете назвать свой вариант:

Синтаксис

Параметры

Примечания

Научим основам Python и Data Science на практике

Это не обычный теоритический курс, а онлайн-тренажер, с практикой на примерах рабочих задач, в котором вы можете учиться в любое удобное время 24/7. Вы получите реальный опыт, разрабатывая качественный код и анализируя реальные данные.

Источник

Packaging and distributing projects¶

This section covers the basics of how to configure, package and distribute your own Python projects. It assumes that you are already familiar with the contents of the Installing Packages page.

The section does not aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing.

For more reference material, see Building and Distributing Packages in the setuptools docs, but note that some advisory content there may be outdated. In the event of conflicts, prefer the advice in the Python Packaging User Guide.

Requirements for packaging and distributing¶

You’ll need this to upload your project distributions to PyPI (see below ).

Configuring your project¶

Initial files¶

setup.py¶

The most important file is setup.py which exists at the root of your project directory. For an example, see the setup.py in the PyPA sample project.

setup.py serves two primary functions:

setup.cfg¶

setup.cfg is an ini file that contains option defaults for setup.py commands. For an example, see the setup.cfg in the PyPA sample project.

README.rst / README.md¶

All projects should contain a readme file that covers the goal of the project. The most common format is reStructuredText with an “rst” extension, although this is not a requirement; multiple variants of Markdown are supported as well (look at setup() ’s long_description_content_type argument).

MANIFEST.in¶

A MANIFEST.in is needed when you need to package additional files that are not automatically included in a source distribution. For details on writing a MANIFEST.in file, including a list of what’s included by default, see “ Including files in source distributions with MANIFEST.in ”.

For an example, see the MANIFEST.in from the PyPA sample project.

MANIFEST.in does not affect binary distributions such as wheels.

LICENSE.txt¶

Every package should include a license file detailing the terms of distribution. In many jurisdictions, packages without an explicit license can not be legally used or distributed by anyone other than the copyright holder. If you’re unsure which license to choose, you can use resources such as GitHub’s Choose a License or consult a lawyer.

For an example, see the LICENSE.txt from the PyPA sample project.

Although it’s not required, the most common practice is to include your Python modules and packages under a single top-level package that has the same name as your project, or something very close.

For an example, see the sample package that’s included in the PyPA sample project.

setup() args¶

As mentioned above, the primary feature of setup.py is that it contains a global setup() function. The keyword arguments to this function are how specific details of your project are defined.

The most relevant arguments are explained below. Most of the snippets given are taken from the setup.py contained in the PyPA sample project.

Start & end with an ASCII letter or digit.

version ¶

This is the current version of your project, allowing your users to determine whether or not they have the latest version, and to indicate which specific versions they’ve tested their own software against.

Versions are displayed on PyPI for each release if you publish your project.

See Choosing a versioning scheme for more information on ways to use versions to convey compatibility information to your users.

If the project code itself needs run-time access to the version, the simplest way is to keep the version in both setup.py and your code. If you’d rather not duplicate the value, there are a few ways to manage this. See the “ Single-sourcing the package version ” Advanced Topics section.

description ¶

Give a short and long description for your project.

description is also displayed in lists of projects. For example, it’s visible in the search results pages such as https://pypi.org/search/?q=jupyter, the front-page lists of trending projects and new releases, and the list of projects you maintain within your account profile (such as https://pypi.org/user/jaraco/).

Give a homepage URL for your project.

author ¶

Provide details about the author.

license ¶

The license argument doesn’t have to indicate the license under which your package is being released, although you may optionally do so if you want. If you’re using a standard, well-known license, then your main indication can and should be via the classifiers argument. Classifiers exist for all major open-source licenses.

The license argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license. As a general rule, it’s a good idea to use a standard, well-known license, both to avoid confusion and because some organizations avoid software whose license is unapproved.

classifiers ¶

Provide a list of classifiers that categorize your project. For a full listing, see https://pypi.org/classifiers/.

Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the python_requires argument.

keywords ¶

List keywords that describe your project.

project_urls ¶

List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development. The string of the key is the exact text that will be displayed on PyPI.

packages ¶

Set packages to a list of all packages in your project, including their subpackages, sub-subpackages, etc. Although the packages can be listed manually, setuptools.find_packages() finds them automatically. Use the include keyword argument to find only the given packages. Use the exclude keyword argument to omit packages that are not intended to be released and installed.

py_modules ¶

install_requires ¶

python_requires ¶

If your project only runs on certain Python versions, setting the python_requires argument to the appropriate PEP 440 version specifier string will prevent pip from installing the project on other Python versions. For example, if your package is for Python 3+ only, write:

If your package is for Python 2.6, 2.7, and all versions of Python 3 starting with 3.3, write:

Support for this feature is relatively recent. Your project’s source distributions and wheels (see Packaging your project ) must be built using at least version 24.2.0 of setuptools in order for the python_requires argument to be recognized and the appropriate metadata generated.

In addition, only versions 9.0.0 and higher of pip recognize the python_requires metadata. Users with earlier versions of pip will be able to download & install projects on any Python version regardless of the projects’ python_requires values.

package_data ¶

The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package.

data_files ¶

Each (directory, files) pair in the sequence specifies the installation directory and the files to install there. The directory must be a relative path (although this may change in the future, see wheel Issue #92), and it is interpreted relative to the installation prefix (Python’s sys.prefix for a default installation; site.USER_BASE for a user installation). Each file name in files is interpreted relative to the setup.py script at the top of the project source distribution.

scripts ¶

Although setup() supports a scripts keyword for pointing to pre-made scripts to install, the recommended approach to achieve cross-platform compatibility is to use console_scripts entry points (see below).

entry_points ¶

Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on.

For more information, see the section on Advertising Behavior from the setuptools docs.

The most commonly used entry point is “console_scripts” (see below).

console_scripts ¶

Choosing a versioning scheme¶

Standards compliance for interoperability¶

Here are some examples of compliant version numbers:

To further accommodate historical variations in approaches to version numbering, PEP 440 also defines a comprehensive technique for version normalisation that maps variant spellings of different version numbers to a standardised canonical form.

Scheme choices¶

Semantic versioning (preferred)¶

For new projects, the recommended versioning scheme is based on Semantic Versioning, but adopts a different approach to handling pre-releases and build metadata.

The essence of semantic versioning is a 3-part MAJOR.MINOR.MAINTENANCE numbering scheme, where the project author increments:

MAJOR version when they make incompatible API changes,

MINOR version when they add functionality in a backwards-compatible manner, and

MAINTENANCE version when they make backwards-compatible bug fixes.

Adopting this approach as a project author allows users to make use of “compatible release” specifiers, where name

= X.Y requires at least release X.Y, but also allows any later release with a matching MAJOR version.

Python projects adopting semantic versioning should abide by clauses 1-8 of the Semantic Versioning 2.0.0 specification.

Date based versioning¶

Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature.

A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number.

Serial versioning¶

This is the simplest possible versioning scheme, and consists of a single number which is incremented every release.

While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility.

Hybrid schemes¶

Combinations of the above schemes are possible. For example, a project may combine date based versioning with serial versioning to create a YEAR.SERIAL numbering scheme that readily conveys the approximate age of a release, but doesn’t otherwise commit to a particular release cadence within the year.

Pre-release versioning¶

Regardless of the base versioning scheme, pre-releases for a given final release may be published as:

zero or more dev releases (denoted with a “.devN” suffix)

zero or more alpha releases (denoted with a “.aN” suffix)

zero or more beta releases (denoted with a “.bN” suffix)

zero or more release candidates (denoted with a “.rcN” suffix)

pip and other modern Python package installers ignore pre-releases by default when deciding which versions of dependencies to install.

Local version identifiers¶

A local version identifier takes the form

Working in “development mode”¶

You can install a project in “editable” or “develop” mode while you’re working on it. When installed as editable, a project can be edited in-place without reinstallation: changes to Python source files in projects installed as editable will be reflected the next time an interpreter process is started.

To install a Python package in “editable”/”development” mode Change directory to the root of the project directory and run:

You may want to install some of your dependencies in editable mode as well. For example, supposing your project requires “foo” and “bar”, but you want “bar” installed from VCS in editable mode, then you could construct a requirements file like so:

The first line says to install your project and any dependencies. The second line overrides the “bar” dependency, such that it’s fulfilled from VCS, not PyPI.

If, however, you want “bar” installed from a local directory in editable mode, the requirements file should look like this, with the local paths at the top of the file:

Otherwise, the dependency will be fulfilled from PyPI, due to the installation order of the requirements file. For more on requirements files, see the Requirements File section in the pip docs. For more on VCS installs, see the VCS Support section of the pip docs.

Lastly, if you don’t want to install any dependencies at all, you can run:

Packaging your project¶

Before you can build wheels and sdists for your project, you’ll need to install the build package:

Источник