Sinto muito pela parede de texto, mas estou tentando fornecer um bom histórico para minha pergunta. Na verdade, há um milhão de perguntas aqui porque estou completamente confuso. Eu recentemente aprendi alguma programação Python e fiz uma aplicação Windows. Agora eu quero implementar esse aplicativo e algumas outras idéias para o Ubuntu e lançá-las como código aberto GPL-3. Embora, eu gostaria de manter o código possível para rodar em qualquer sistema (ou pelo menos no Ubuntu e no Windows).
Então, para saber como funciona o empacotamento do Ubuntu, examinei rapidamente o aplicativo usado no Showdown do desenvolvedor de aplicativos recentemente. Mas a estrutura da pasta e os arquivos que ela cria não faz sentido para mim. Então eu li o Guia de empacotamento do Ubuntu e o Processo de Revisão de Applicaton com todos os links, bem como os Política do Debian Python . Mas todo esse texto só funcionou para me deixar mais confuso sobre o modo como cria arquivos e pastas rapidamente.
O caminho mais rápido?
Então, é isso que eu entendo rapidamente (supondo que o nome do meu projeto seja proj):
proj/bin = um único arquivo que será copiado para /usr/share/bin/proj.py para ativar a execução do aplicativo a partir de um caminho global? Mas isso estaria violando as regras do "Processo de Revisão de Aplicação", certo?
proj/data/* = arquivos que deveriam estar em / usr / share / proj / *, certo? Mas isso também estaria violando as regras do "Processo de Revisão de Aplicação"?
proj/help/C/* = alguma documentação HTML, eu acho, que deveria ir em / usr / share / doc / proj / e que funciona bem com "Application Review ", mas por que o nome da pasta" C "e não apenas" proj "?
proj/tests/ = algum tipo de arquivo para um pacote" teste "dentro do Python. Eu acho que isso é ótimo, ansioso para aprender o que é.
proj/proj/ = alguns arquivos que parecem apenas ligar para novos arquivos na pasta proj_lib? Parece desnecessário, e eu não entendo porque eles estão aqui.
proj/proj_lib/ = o código fonte, eu acho?
Em seguida, também cria rapidamente proj/apport e proj/etc/apport* , o que não faço ideia do que eles fazem ou porque são adicionados.
Agora, a parte realmente confusa é a estrutura do arquivo. Não parece nada que eu tenha visto antes. E para ser honesto, parece muito complicado de uma forma desnecessária. Abaixo desta seção, descreverei a maneira como eu criaria minha própria estrutura de arquivos de projeto, o que pode ajudar a descrever por que isso é tão confuso para mim. Mas primeiro, meu entendimento da maneira rápida (note que meu entendimento pode estar errado neste momento).
Primeiro, o setup.py . Este arquivo contém uma função chamada update_config () que apenas carrega outro arquivo chamado proj / proj_lib / projconfig.py. Mas esse arquivo config.py não parece conter nada que seria útil para manter separado do setup.py? Na verdade, há muitas coisas que eu nunca vi ninguém sugerir colocar em um arquivo setup.py antes. O setup.py também contém um nome de arquivo codificado apontando para o ícone SVG, e caso contrário, apenas copia o arquivo desktop.in em si mesmo, então porque não apenas as alterações feitas diretamente no arquivo desktop.in sem essa função na configuração .py? Então existe outra função para criar um subdiretório proj / data / share / proj e copiar o arquivo desktop.in, que não entendi o propósito? Por que ter uma função que faz isso quando você pode simplesmente ter o arquivo lá originalmente? Então depois de todo esse código sem sentido aparecer algo que realmente parece um setup.py regular.
Agora, o proj/bin/proj.py , que eu suponho, deve ser usado para iniciar o aplicativo? Isso parece apenas remapear / usr / para /opt/extras.ubuntu.com/ em uma variável de syspath não declarada anteriormente. Então eu acho que isso é para acomodar as regras no "Processo de Revisão de Aplicação" para aplicativos que estão usando nomes de pasta padrão para todos os outros sabores do Linux? É justo, não entendo, mas posso viver com isso. Após esse remapeamento dos diretórios, esse arquivo passa a chamar o proj / proj / init .py.
proj/proj/__init__.py é a maneira padrão de definir como iniciar um módulo, eu acho? Mas em vez de ter algum código que realmente faz alguma coisa, esse arquivo simplesmente executa a classe da janela principal, que está localizada em outro arquivo.
proj/proj_lib/ também possui um arquivo init .py que não entendi o propósito de. Em seguida, há um Window.py que parece conter a funcionalidade do aplicativo e chama outros arquivos py da janela, como sobre o diálogo etc.
A maneira como eu fiz meu aplicativo
Minha estrutura de pastas é assim:
proj/
proj/ui
proj/imageformats # necessary for imports to work
proj/sqldrivers # necessary for imports to work
Na pasta proj/ , tenho meu setup.py e meu proj.py, que inicia meu aplicativo. No meu proj.Eu tenho toda a funcionalidade da janela principal, chamando algumas outras janelas e funções com importações, e no final deste arquivo está a função main () que inicia o aplicativo.
A pasta proj/ui/ contém todos os meus arquivos .ui feitos com o Qt Designer.
As outras pastas estão lá apenas para fornecer alguns arquivos que farão o aplicativo funcionar quando empacotado com o py2exe para Windows. Basicamente, são os arquivos que seriam fornecidos através de dependências no Ubuntu.
Observe que essa configuração funciona muito bem para o desenvolvimento do Windows. Eu uso py2exe para construir um executável que acaba em uma pasta proj/dist/ , e eu posso apenas copiar os arquivos nesta pasta e ele funcionará em qualquer máquina Windows.
Como posso combinar isso?
Eu passei alguns dias tentando ler a documentação. Não há praticamente nada que eu possa encontrar rapidamente, exceto o tutorial básico e as coisas em App Developer Showdown Workshops. Não consigo encontrar nada que me ajude a entender a estrutura de pastas sugerida rapidamente.
Pelo que li, eu poderia usar os.environ['HOME'] para criar um caminho para ~ / .config / proj.conf no Ubuntu ou C: /Users/username/.config/proj.conf no Windows. Até agora eu posso continuar a cruzar o código da plataforma. Mas então, com a divisão em / bin e / etc e / opt, vou começar a encontrar alguns problemas. Claro, eu poderia como último recurso manter duas cópias do código - uma configurada para o Ubuntu e outra para o Windows. Mas eu ainda quero uma estrutura de pastas similar para facilitar a transferência de alterações de código.
Deve haver alguém que já tenha uma boa solução para isso. E talvez essa pessoa também possa (além de dar um exemplo de como fazer isso em uma plataforma cruzada) descrever por que há uma longa cadeia de arquivos chamando outros arquivos chamando outros arquivos no padrão de configuração rápida? Claro, agora estou assumindo que usa rapidamente algum tipo de modelo recomendado para o Ubuntu. Se não for esse o caso, gostaria de obter sugestões sobre o que seria uma estrutura de pastas recomendada para distribuir uma aplicação através de repositórios do Ubuntu?