Os projetos python precisam de um MANIFEST.in, e o que deve haver nele?


120

O guia "Python Distribute" (estava em python-distribute.org, mas o registro expirou) me diz para incluir doc/txtarquivos e os .pyarquivos são excluídos do MANIFEST.inarquivo

A documentação do sourcedist me diz que apenas o sdist usa MANIFEST.ine inclui apenas o arquivo que você especificar e para incluir .pyarquivos. Ele também me diz para usar: python setup.py sdist --manifest-onlypara gerar um MANIFEST, mas o python me diz que isso não existe

Eu aprecio que eles são de diferentes versões do python e o sistema de distribuição está em uma bagunça completa, mas supondo que eu esteja usando o python 3 e setuptools(o novo que inclui distribuição, mas agora chamado de setuptools, não o antigo setuptools que foi preterido apenas para ferramentas de distribuição para ser trazido de volta para distribuir e distribuir renomeado para setuptools .....)

e estou seguindo a estrutura de pasta e setup.pyarquivo "padrão" ,

  1. Eu preciso de um MANIFEST.in?
  2. O que deve estar nele?
  3. Quando todos esses diferentes sistemas e métodos de pacotes serão transformados em um único processo simples?

Respostas:


117

Re: "Preciso de um MANIFEST.in?

Não, você não precisa usar MANIFEST.in. Ambos, distutilse setuptoolsestão incluindo no pacote de distribuição de código-fonte todos os arquivos mencionados em setup.py- módulos, arquivos de pacote python README.txte test/test*.py. Se isso é tudo que você deseja ter no pacote de distribuição, você não precisa usar MANIFEST.in.

Se você deseja manipular (adicionar ou remover) arquivos padrão a serem incluídos, você deve usar MANIFEST.in.

Re: O que deve estar nele?

O procedimento é simples:

  1. Certifique-se de setup.pyincluir (por meio de setupargumentos) todos os arquivos que considera importantes para o programa executar (módulos, pacotes, scripts ...)

  2. Esclareça se há alguns arquivos para adicionar ou alguns arquivos para excluir. Se nenhum dos dois for necessário, não há necessidade de uso MANIFEST.in.

  3. Se MANIFEST.infor necessário, crie-o. Normalmente, você adiciona tests*/*.pyarquivos, README.rstse não usar README.txt, docsarquivos e possivelmente alguns arquivos de dados para o conjunto de testes, se necessário.

Por exemplo:

include README.rst
include COPYING.txt

Para testá-lo, execute python setup.py sdiste examine o tarball criado em dist/.

Quando todos esses sistemas de pacotes diferentes ...

Comparar a situação de hoje com a de 2 anos atrás - a situação é muito melhor - setuptoolsé o caminho a percorrer. Você pode ignorar o fato, distutilsestá um pouco quebrado e é base de nível baixo para setuptoolscomo setuptoolsdeve cuidar de esconder essas coisas de você.

EDIT : Últimos projetos que uso pbrpara a construção de pacotes de distribuição com três linhas setup.pye o resto sendo em setup.cfge requirements.txt. Não há necessidade de se preocupar com MANIFEST.inoutras coisas estranhas. Mesmo que o pacote mereça um pouco mais de documentação. Veja http://docs.openstack.org/developer/pbr/


1
Em minha experiência limitada, parece que se você quiser incluir arquivos que não estão dentro de um módulo python (dir com init .py), você deve usar MANIFEST.in e usar o comando sdist(significa: distribuição de origem ). Se você considerar isso bdiste bdist_wheelforem binários e destinados apenas a serem instalados em seu caminho python, isso faz sentido. (Para onde iriam esses arquivos e diretórios que não são do módulo? Para dentro /usr/local/lib/python2.7/dist-packages/? Certamente não.) Mas vale a pena mencionar, pois é confuso ver o arquivo criado e eles não incluem os arquivos.
Bruno Bronosky,

7
Para evitar o inevitável package_datae as data_filesrecomendações, que estão fora do escopo, vou continuar. package_datalista o arquivo que foi instalado com o seu pacote e dist-packages/yourpackageque teria sido ignorado porque não tem um nome * .py. data_fileslista os arquivos que são instalados fora do seu pacote. Cada entrada especifica um caminho de destino com o prefixo sys.prefixse for relativo ou criado diretamente (se as permissões permitirem) se começar com um /.
Bruno Bronosky,

2
@JanVlcinsky é importante saber o que está e [mais importante] não está incluído nos diferentes formatos de distribuição. Tenho um projeto público que distribuo apenas por meio da distribuição de origem porque incluo um arquivo boto.sample.cfg (que contém uma credencial AWS IAM falsa) fora do pacote (na raiz) e as distribuições binárias não o incluem. Eu faço compilações binárias privadas para implantação em produção que têm data_files = [('/ etc /', ['boto.cfg'])]. Se você deseja distribuir arquivos não-py, precisa saber como essas coisas funcionam.
Bruno Bronosky,

2
@MichaelGoerz Honestamente, eles não deveriam. Essa resposta é antiga e sugerir também não pbré uma boa ideia.
Arne

1
@Ame eu concordo, as coisas mudaram. Atualmente estou convertendo a maioria dos meus projetos de pbr para poesia
Jan Vlcinsky

7

Pergunta antiga, nova resposta:

Não, você não precisa MANIFEST.in. No entanto, para setuptoolsfazer o que você (normalmente) quer dizer, você precisa usar o setuptools_scm, que desempenha a função de MANIFEST.inem 2 lugares-chave:

  • Ele garante que todos os arquivos relevantes sejam empacotados ao executar o sdistcomando (onde todos os arquivos relevantes são definidos como "todos os arquivos sob controle de origem")
  • Ao usar include_package_datapara incluir dados do pacote como parte de buildou bdist_wheel. (novamente: arquivos sob controle de origem)

O entendimento histórico MANIFEST.iné: quando você não tem um sistema de controle de origem, você precisa de algum outro mecanismo para distinguir entre "arquivos de origem" e "arquivos que estão em seu diretório de trabalho". No entanto, seu projeto está sob controle de origem (certo ??), portanto, não há necessidade MANIFEST.in. Mais informações neste artigo .

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.