Como implantar um aplicativo Python com bibliotecas como fonte sem mais dependências?

StackOverflow https://stackoverflow.com/questions/527510

Pergunta

Fundo : Eu tenho uma pequena aplicação Python que faz a vida para os desenvolvedores lançando software em nossa empresa um pouco mais fácil. Eu criar um executável para Windows usando py2exe. A aplicação, bem como o binário são verificados no Subversion. Distribuição acontece por pessoas apenas verificando o diretório de SVN. O programa tem cerca de 6 dependências diferentes da biblioteca Python (por exemplo ElementTree, Mako)

A situação : Os desenvolvedores querem cortar na origem desta ferramenta e, em seguida, executá-lo sem ter que construir o binário. Atualmente, isto significa que eles precisam de um 2.6 interpretador Python (que é bom) e também tem as 6 bibliotecas instaladas localmente usando easy_install.

O Problema

  • Este não é um público, ambiente open source clássica: Eu estou dentro de uma rede corporativa, a ferramenta nunca vai deixar o "jardim murado" e temos barreiras sério inconveniente para chegar à internet fora (NTLM autenticação de proxies e / ou máquinas sem acesso direto à Internet).
  • Eu quero que os obstáculos para começar a cortar em esta ferramenta para ser mínima: ninguém deveria ter que caçar para a dependência direita na versão direita, eles devem ter para executar tão pouco configuração possível. Otimamente os pré-requisitos seria ter uma instalação Python e apenas verificando o programa do Subversion.

Anecdote : A mais auto-suficientes, o processo é mais fácil é a repeti-la. Eu tinha a minha máquina trocado por um novo e passou pelo processo desagradável de ter de fazer engenharia reversa as dependências, distutils reinstalar, caçar as bibliotecas on-line e levá-los para instalar (ver restrições de internet corporativos acima).

Foi útil?

Solução

Eu às vezes uso a abordagem que eu descrevo abaixo, pela mesma razão exata que @Boris afirma: Eu preferiria que o uso de algum código é tão fácil como a) svn checkout / update - b) ir

.

Mas para o registro:

  • Eu uso virtualenv / easy_install maior parte do tempo.
  • Eu concordo em certa medida, para as critisisms por @Ali A e @ S. Lott

De qualquer forma, o uso abordagem que depende modificando sys.path, e funciona assim:

  • Exigir python e setuptools (para permitir código de carregamento de ovos) em todos os computadores que irão utilizar o seu software.
  • Organize sua estrutura de diretórios isto: 
project/
    *.py
    scriptcustomize.py
    file.pth

    thirdparty/
        eggs/
            mako-vNNN.egg
            ... .egg
        code/
            elementtree\
                *.py
            ...
  • No seu script (s) de nível superior incluem o seguinte código na parte superior: 
from scriptcustomize import apply_pth_files
apply_pth_files(__file__)
  • Adicione scriptcustomize.py para a pasta de projeto: 
import os
from glob import glob
import fileinput
import sys

def apply_pth_files(scriptfilename, at_beginning=False):
    """At the top of your script:
    from scriptcustomize import apply_pth_files
    apply_pth_files(__file__)

    """
    directory = os.path.dirname(scriptfilename)
    files = glob(os.path.join(directory, '*.pth'))
    if not files:
        return
    for line in fileinput.input(files):
        line = line.strip()
        if line and line[0] != '#':
            path = os.path.join(directory, line)
            if at_beginning:
                sys.path.insert(0, path)
            else:
                sys.path.append(path)
  • Adicionar um ou mais * arquivo (s) .pth para sua pasta projeto. Em cada linha, colocar uma referência a um diretório com pacotes. Por exemplo: 
# contents of *.pth file
thirdparty/code
thirdparty/eggs/mako-vNNN.egg
  • I "tipo-de", como esta abordagem. O que eu gosto: é semelhante à forma como arquivos * .pth trabalho, mas para programas individuais em vez de todo o seu site-packages. O que eu não gosto:. Ter que adicionar as duas linhas no início dos scripts de nível superior
  • Novamente: Eu uso virtualenv maior parte do tempo. Mas eu tendem a usar virtualenv para projetos onde eu tenho um controle rígido do cenário de implantação. Nos casos em que não tenho controlo apertado, eu tendem a usar a abordagem que eu descrevi acima. Isso torna muito fácil para empacotar um projeto como um zip e têm o usuário final "instalar"-lo (por descompactar).

Outras dicas

Basta usar virtualenv - é uma ferramenta para criar ambientes Python isolados. Você pode criar um script set-up e distribuir o grupo inteiro se quiser.

"Eu não gosto do fato de que os desenvolvedores (ou me a partir de uma máquina nova e limpa) tem que saltar através dos aros Distutils de ter que instalar as bibliotecas localmente antes que eles possam começar"

Por quê?

O que - especificamente -? Está errado com este

Você fez isso para criar o projeto. Seu projeto é para que os outros populares querer fazer o mesmo.

Eu não vejo um problema. Por favor, atualize sua pergunta com problemas específicos que você precisa resolvidos. Não gostando da maneira de código aberto é distribuído não é um problema. - É a maneira que as obras de código aberto

Editar . O "jardim murado" não importa muito.

Escolha 1. Você poderia, BTW, construir um "instalador" que corre easy_install 6 vezes para eles.

escolha 2. Você pode salvar todos os kits de instalação que easy_install teria usado. Em seguida, você pode fornecer um script que faz uma descompactação e uma python setup.py install para todos os seis.

Escolha 3. Você pode fornecer uma versão compactada do seu site-packages. Depois que instalar o Python, eles descompactar seu diretório site-packages em `C:. \ Python2.5 \ lib \ site-packages``

Escolha 4. Você pode construir seu próprio kit instalador MSI para o seu ambiente Python.

Escolha 5. Você pode hospedar seu próprio pypi-como servidor e fornecer um easy_install que verifica seu servidor pela primeira vez.

Eu concordo com as respostas por Nosklo e S. Lott. (+1 para ambos)

Posso apenas acrescentar que o que você quer fazer é realmente um idéia terrível .

Se você quiser realmente as pessoas a cortar em seu código, eles vão precisar de alguma compreensão das bibliotecas envolvidas, como eles funcionam, o que eles são, de onde vêm, a documentação de cada etc Claro que fornecê-los com um script de inicialização , mas além disso você será Molly-mimando a tal ponto que eles estão à nora.

Depois, há questões específicas, tais como "o que se um usuário quer instalar uma versão diferente ou implementação de uma biblioteca?", Um exemplo gritante aqui é ElementTree, pois isso tem um número de implementações.

Eu não estou sugerindo que esta é uma ótima idéia, mas geralmente o que fazer em situações como essas é que eu tenho um Makefile, verificado em subversão, que contém regras fazem para buscar todas as bibliotecas dependentes e instalá-los. O makefile pode ser inteligente o suficiente para só se aplicam as bibliotecas dependentes se eles não estiverem presentes, pelo que esta pode ser relativamente rápido.

Um novo colaborador no projeto simplesmente verifica fora de subversão e, em seguida, digita "make".

Esta abordagem pode funcionar bem para você, uma vez que o público já está acostumado com a idéia de usar checkouts subversão como parte de seu processo de buscar. Além disso, ele tem a propriedade agradável que todo o conhecimento sobre o seu programa, incluindo suas dependências externas, são capturados no repositório de código-fonte.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top