2

このビデオを見て、ソースリリースツールで遊んでみました。

まず、ドキュメントの不確かな部分は次のとおりです。

ソースリリースを作成するには、buildout-source-releaseスクリプトを実行し、ファイルURLまたはSubversionURL[3]と使用する構成ファイルの名前を渡すだけです。ファイルURLはテストに役立ち、Subversion以外のソースコード管理システムで使用できます。

それらはどのファイルURLを意味しますか？プロジェクトルート？

次に、他の引数はbuildout.cfgへのパスである必要があります。プロジェクトで通常のbuildout.cfgを使用すると、sourcereleaseはプロジェクト全体を再ビルドします。途中でクラッシュした場合bin/buildout-source-releaseは、なくなってしまったので、もう一度走らなければなりませんbin/buildout。これは避けられますか？

第三に、buildout-source-releaseパッケージをダウンロードします（それらが固定されていて、それらのバージョンがにある場合でも~/.buildout）。buildout.cfgで指定されたカスタムパッケージキャッシュも使用します。

[buildout]
index = http://pypi.*****.com

bsrもそれを無視します！もちろん、私が持っている約50のパッケージの中には、現在利用できないものもあります（ほとんどの場合、Scipyサーバーがダウンしています）。

ローカルパッケージソースを再利用するにはどうすればよいですか？

4

1 に答える 1

1

このスクリプトは、提供された Subversion URL を一時ディレクトリにチェックアウトすることで、最初から完全なディストリビューションを作成し、2 番目のパラメーターで指定されたディレクトリでビルドアウト構成ファイルを実行します。

または、Subversion リポジトリの代わりに、ファイル URL が指すディレクトリ構造をコピーすることもできます。後者は、SVN リポジトリ以上のものをサポートするための応急処置です。たとえば、Git プロジェクトの作業コピーを作成し、それをfile:///path/to/git/wc/URL でポイントします。

このスクリプトは、ビルドアウトの完全にスタンドアロンのコピーを構築します。そのためには、空のキャッシュを作成し、レシピに仕事をさせることでそれを埋める必要があります。その後、インストール スクリプトはそのキャッシュを再利用してインストールを実行します。

また、レシピは独自の手段を使用してキャッシュをチェックし、リソースをダウンロードします。buildout はレシピに代わってそれを維持しません。したがって、既存のキャッシュから何かを再利用できるかどうかをスクリプトが判断するためのメカニズムは現在のところありません。

于 2012-09-24T12:34:25.167 に答える