Pergunta

Estou pensando como organizar uma aplicação python implantado que terá um

  1. script executável localizado em / usr / bin / que irá fornecer um CLI a funcionalidade implementada no
  2. Uma biblioteca instalada para onde quer que o atual diretório site-packages é.

Agora, hoje, eu tenho a seguinte estrutura de diretório em minhas fontes:

foo.py
foo/
  __init__.py
  ...

que eu acho que não é a melhor maneira de fazer as coisas. Durante o desenvolvimento, tudo funciona como esperado, no entanto, quando implantado, o código "de foo FooObject importação" em foo.py aparentemente tentativas para si foo.py de importação, que não é o comportamento que eu estou procurando.

Portanto, a questão é o que é a prática padrão de orquestrar situações como esta? Uma das coisas que eu poderia pensar é, ao instalar, foo.py renomeação apenas foo, que o impede de importação em si, mas que parece um pouco estranho ...

Outra parte do problema, suponho, é que é um desafio de nomeação. Talvez chamar o foo-bin.py script executável?

Foi útil?

Solução

Este artigo é muito bom, e mostra-lhe uma boa maneira de fazê-lo. O segundo item da Do lista responde a sua pergunta.

cópia descarada colar:

estrutura de sistema de arquivos de um projeto Python

por Jp Calderone

Do:

  • nomear o diretório algo relacionado ao seu projeto. Por exemplo, se o seu projeto é denominado "Twisted", o nome do diretório de nível superior para a sua fonte arquivos Twisted. Ao fazer lançamentos, você deve incluir um número de versão sufixo:. Twisted-2.5
  • criar um Twisted/bin diretório e colocar os executáveis ??lá, se você tem algum. Não dar-lhes uma .py extensão, mesmo que sejam Python Arquivos Fonte. Não coloque qualquer código em eles, exceto uma importação de e chamada para um principal função definida em outro lugar em seus projetos.
  • Se o seu projeto é expressável como um único arquivo fonte Python, em seguida, colocá-lo para o diretório e nomeá-la algo relacionado ao seu projeto. Para exemplo, Twisted/twisted.py. Se vocês precisar de vários arquivos de origem, criar um pacote em vez (Twisted/twisted/, com um vazio Twisted/twisted/__init__.py) e lugar sua fonte de arquivos nele. Por exemplo, Twisted/twisted/internet.py.
  • colocar os testes de unidade em um sub-pacote do seu pacote (Nota - este meio que o único arquivo fonte Python opção acima era um truque - você sempre precisa de pelo menos um outro arquivo para o seu testes de unidade). Por exemplo, Twisted/twisted/test/. Claro, make -lo um pacote com Twisted/twisted/test/__init__.py. Testes lugar em arquivos como Twisted/twisted/test/test_internet.py.
  • Twisted/README add e Twisted/setup.py para explicar e instalar o seu software, respectivamente, Se você é sensação agradável.

Do not:

  • colocar a sua fonte em um diretório chamado src ou lib. Isso torna difícil para executar sem instalação.
  • colocar seus testes fora de seu pacote Python. Isto torna mais difícil executar os testes contra um instalado versão.
  • criar um pacote que só tem um __init__.py e, em seguida, colocar todo seu código em __init__.py. Basta fazer um módulo em vez de um pacote, é mais simples.
  • tentar chegar com hacks mágicas para fazer Python capaz de importar o módulo ou pacote sem ter o suplemento de usuário o diretório que contém-lo ao seu caminho de importação (quer via PYTHONPATH ou algum outro mecanismo). Você não vai lidar corretamente todos os casos e usuários vai ficar com raiva de você quando o seu software não funciona em sua meio ambiente.

Outras dicas

Distutils suporta a instalação de módulos, pacotes e roteiros . Se você criar um setup.py distutils que se refere a foo como um pacote e foo.py como um script, então foo.py deve ser instalado para /usr/local/bin ou qualquer que seja o script apropriado caminho de instalação está no OS alvo, eo pacote foo deve ser instalado para o diretório site_packages .

Você deve chamar o foo apenas executável, não foo.py, em seguida, tenta foo importação não vai usá-lo.

Como para nomeá-lo corretamente: isso é difícil de responder em abstrato; seria preciso saber o que especificamente ele faz. Por exemplo, se configura e controles, chamando-o -config ou CTL pode ser apropriada. Se é uma API shell para a biblioteca, ele deve ter o mesmo nome da biblioteca.

O módulo CLI é uma coisa, o pacote que o suporta é outra coisa. Não confundir os nomes verga foo módulo (em um foo.py arquivo) eo foo pacote (em um foo diretório com um __init__.py arquivo).

Você tem duas coisas nomeadas foo: um módulo e um pacote. O que mais você quer para citar foo? Uma aula? Uma função? Uma variável?

Escolha um nome diferente para o módulo foo ou o pacote foo. foolib, por exemplo, é um nome de pacote popular.

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