2016-08-12：一般討論

時間：14:00 UTC

視訊連結：https://hangouts.google.com/call/v5olhwzpfzgzpoq5i3wthjpqpie

2016-07-22：一般討論

與會者

Eric Dill

Phil Elson

Michael Sarahan

John Kirkham

常設項目

• 有多少個 repo？
• 有多少貢獻者？
• 新的核心開發人員？

議程

• 預發行版本

  *   Python prerelease done at [conda forge/python feedstock#45](https://github.com/conda-forge/python-feedstock/pull/45) - is this an example to follow?

  • 我們是否有關於如何執行此操作的文件？

  • 等待 PR：conda forge/scikit image feedstock#2

  • Conda 本身：conda/conda#3262#issuecomment-239410077

  • 關於預發行管道命名的提案

        *   embed the package name in the anaconda label so that you can specify exactly which pre-release things to install

    • 從 main 以外的標籤指定 conda install 命令是：** **

              *   **`conda** install -c conda-forge/label/rc <package>`
      
      *   So  if you embed, for example, "matplotlib-" in the label name, then you  can specifically install *just* the matplotlib pre-release with:
      
              *   `conda install -c conda-forge/label/matplotlib-rc matplotlib`

• 狀態頁面

  *   Have dependencies.
  • 一些用於網路服務的程式碼

• Feedstock 哲學：顯式 vs 隱式 / 可重現 vs 冗餘

• OSX - 回到可用、連貫的堆疊

  *   libc++ (clang) vs libstdc++ (gcc/g++)

  • clang 所需的最低 OSX 版本（我想是 10.8？）

  • 實際上，clang 從 10.7 開始即可使用。因此，如果考慮您的相容性限制，這將是可行的。

  • 此外，我看到的所有參考文獻都表明，這仍然會支援 C++11。

  • 與預設值（在 10.7 上建置，使用 gcc）的相容性 - 人們會在何處遇到問題？ 我認為只有在混合套件時 - 我們如何確保我們擁有所有需要的套件？

• 改進基礎架構

  *   Finish out GitHub API issues ( [conda forge/conda forge.github.io#172](https://github.com/conda-forge/conda-forge.github.io/issues/172) )

  • 使用 staged-recipes 實現更好的工作流程

        *   Fast finish AppVeyor on merge ( [conda forge/staged recipes#1142](https://github.com/conda-forge/staged-recipes/pull/1142) )
    • 移除 Travis CI 矩陣（conda forge/staged recipes#1234）
    • 使用 CircleCI 進行 feedstock 生成（conda forge/staged recipes#916）
    • 將 recipes 排除在 PR 之外（conda forge/staged recipes#942）
    • 銀行工作的部分轉換（conda forge/staged recipes#915）

• 底層封裝

• PR-ing 到 staged-recipes 時的基本社群實踐。

• 無需重新討論這個。我仍在撰寫文件，如果準備好了，我將在明天（或 SciPy 後 ;-)）發送連結

• NetCDF（還有 curl/ca-certificates 和 Perl 套件）- 完成了嗎？

  *   curl and ca-certificates are done and available. 
  • Perl 作為此過程的一部分已不再相關

• 通知（我們如何掌握它們）

• 標準化安裝

  *   Mention [`toolchain`](https://github.com/conda-forge/toolchain-feedstock) .
  
          *   Discuss rollout to feedstocks.
  
  *   Get feedback on [`python-toolchain`](https://github.com/conda-forge/staged-recipes/pull/642) 

• MSYS2

  *   Available on defaults - was in conda 4.1.7, but that was pulled.  Coming in 4.1.8.
  • 討論 Ray Donnelly 在 MSYS2 套件上的工作，以及我們希望如何使用這些套件並將其整合到 conda-forge 中。
  • 一些要考慮的用例 OpenBLAS、FFTW、建置工具，以及其他？

• 二進位資料

  *   Do we include it in recipes?
  • 如果有的話，我們允許哪些種類（例如圖示）？
  • 我們如何驗證授權？
  • 我們如何驗證它們是安全的？

• 開發版本：它們在哪裡發生？

  *   Do we do them at conda-forge?
  
          *   Maybe add a label.
  
  *   Do we let others do them with a feedstock on their own repo?
  • 我們如何強制執行我們決定的任何事情？

• Conda-forge 安裝程式

  *   We have Python 3.5 and 3.4 now. Would be nice to complete Python 2.7.
  • 擁有所有依賴項。雖然 conda-build 有一些問題需要解決。
  • 關於安裝程式的許多開放性問題，包括其名稱
  • 我們在哪裡託管安裝程式？ Git 標籤？
  • 如果您釘選到 conda-build 1.21.7，這現在可以正常運作
  • 但是，由於 windows 上 setuptools entrypoints 問題而實際上被阻止，該問題已在 conda 4.2 中修復，但 4.2 尚未發布。 conda 4.2 預計在 8 月底發布

• 管道鏡像

  *   Can this point be a little bit explained? I thought about this as well and would like to contribute to this point.
  
          *   Eric Dill has put together a script for copying a package from one channel to another here: [conda forge/conda forge.github.io#134](https://github.com/conda-forge/conda-forge.github.io/pull/134)
  *   I have a really, really crude script that copies all of the packages in one channel to another that I just put at: [](https://gist.github.com/mwcraig/8473cf840f6d29236d6d8af699404555)[https://gist.github.com/mwcraig/8473cf840f6d29236d6d8af699404555](https://gist.github.com/mwcraig/8473cf840f6d29236d6d8af699404555)
  *   conda-build-all can copy from one channel to another: `conda build-all --inspect-channels conda-forge --upload-channels astropy some_packge_recipe` will copy the `some_package`  from the channel conda-forge to  astropy if it can, or build it if it  doesn't exist on conda-forge. Discussion  about what the desired  behavior should be has started at: [SciTools/conda build all#46](https://github.com/SciTools/conda-build-all/issues/46)

• Feedstock 歷史記錄

  *   Is it sacred?

  • 我們是否 rebase/force push？

        *   If so, under what conditions?

    • 我們如何避免多人同時執行此操作？

              *   I don't think you can.
      
      *   IMHO,  if it's just one author in staged recipes, sure.  If feedstock, no  force push - only to PRs to feedstock.  If people don't mind merge PRs,  it sure is a lot simpler to not rebase.  I have messed up rebasing a few  times recently... =(

• Docker 託管解決方案

  *   Docker Hub builds were broken for a week and a half.
  • 目前已切換到 quay.io。
  • 在 Docker Hub 上鏡像 quay.io 映像。
  • 關於 quay.io 的想法？ 關於一般託管的想法？

• Continuum metadata 請求：我們可以將這些添加到 linter 嗎？

  *   example metadata: [](https://github.com/ContinuumIO/anaconda-recipes/blob/master/anaconda-build/meta.yaml#L36-L44)[https://github.com/ContinuumIO/anaconda-recipes/blob/master/anaconda-build/meta.yaml#L36-L44](https://github.com/ContinuumIO/anaconda-recipes/blob/master/anaconda-build/meta.yaml#L36-L44)
  • 此外，區分摘要（77 或 80 個字元的限制）與描述（無限制）
  • Anaconda verify：最好在中間會合，而不是分歧。 conda-build 可能會整合 anaconda-verify，如果 conda-forge 在此處添加 metadata 會更好。

• Google hangouts 的最大容量為 10 人。 是否值得考慮其他溝通方式，以便每個想參與的人都能參與？

• 也許這個（http://www.freeconferencecalling.com/）是一個選項。

• Bluejeans

• Continuum 擁有 webex。 過去的經驗是，某些 Linux 平台在連線時遇到問題

• 移除 numpy 1.10 並減少我們的建置矩陣。（Numba 現在適用於 numpy 1.11。）

• 來自 graphviz PR 的此評論是我見過的最佳摘要：conda forge/staged recipes#568#issuecomment-225315370

• 感謝您指出這一點。 所描述的解決方案看起來合理，並且比套件名稱加前綴更可取。 太好了！

• 好處是什麼？

• 我們是否會區分 libs 和獨立工具，類似於 Debian？ 我強烈建議這樣做，因為它是 (1) 已建立的，並且 (2) 對於使用者來說更容易理解（如果他想使用一個函式庫，他知道該語言。 如果他想使用一個獨立工具，他不在乎）。（）https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names）

• 是否會進行協調的移動？ 如果沒有，我們如何處理不一致和潛在的衝突（同時安裝 python-h5py 和 h5py）。

  *   we will probably go with meta-packages for conflicting packages

• 簽署套件

• 應該很容易做到。（http://conda.pydata.org/docs/signed-packages.html）

• 之前有人對此感興趣。

• HTTPError: 503 Server Error: Service Unavailable: Back-end server is at capacity for url...

• 似乎我們在正常使用條件下經常遇到這個問題。

• 之前曾討論過在 AppVeyor 上快取套件並嘗試重複使用這些套件來啟動。

• 也許我們需要在所有 CI 上考慮快取。

• 透過 constructor 建置我們自己的類似 Miniconda 的自解壓縮腳本，其中包含套件。

• Continuum 方面已經進行了一些改進，應該有助於解決這個問題。 簡而言之，repodata（給定管道的套件索引）是針對每個 anaconda.org 查詢生成的。 這是不必要的高成本，並且已經實施了一些快取方案。

• 處理移除未釘選/未正確釘選的套件。

• 到目前為止是手動完成的。

• 但這無法很好地擴展。

• 我們應該（半）自動化移除嗎？

• 我們應該熱修復損壞的套件嗎？（conda forge/conda forge.github.io#170）

• 目前無法建置的套件

• 特別是 CI 範圍之外的開源程式碼。

• 範例包括 Qt4、Qt5、可能 PyQt4、可能 PyQt5、gcc、VTK 等。

• 我們如何指示它們是手動建置的？

• 我們可以接受上傳非建置的二進位檔案嗎？

• 我們何時確定某件事可以手動建置？

• 人們在手動建置時應該遵循哪些程序？

  *   Use a standard build docker image, VM, or vagrant file

  • 簽署套件？

  • 在可行的情况下實作可重現的建置（linux）

        *   [](https://reproducible-builds.org/)[https://reproducible-builds.org/](https://reproducible-builds.org/)

• 我們需要在 conda-smithy 的其他地方做出哪些更改？

• 我們可以利用哪些其他建置基礎架構？

  *   Would  be nice to provide some volunteer builder abstraction, so that we could  have an elastic worker farm that would be somewhat resilient.
  • 標準化建置映像檔可能（相對）容易 - 但如何協調？

• Conda RPM：https://github.com/pelson/conda-rpms