conda-forge / conda-forge/conda-forge.github.io
Package naming policies for Julia packages
- Vorherrschende Sprache
- JavaScript
- Sterne
- 170
- Forks
- 320
- Ø Merge
- 2 T. 10 Std.
- Gemergte PRs (30 T.)
- 5
Beschreibung
### Your question:
# Question
How should Julia packages be named within conda-forge?
# Introduction
The [julia-feedstock](https://github.com/conda-forge/julia-feedstock) is now current with upstream Julia at version 1.8.0. Support is currently best on Linux. Mac OS X support is possible on x86_64 and arm64 but needs further work and testing. Windows support is likely not possible within conda-forge without a comprehensive mingw-w64 ecosystem as opposed to a Microsoft Visual C.
We current have two feedstocks employing a dual language Python - Julia strategy within conda-forge:
* https://github.com/ngam/pysr-feedstock
* https://github.com/conda-forge/xbitinfo-feedstock
These two packages primarily are Python interfaces for the following Julia packages:
* [SymbolicRegression.jl](https://github.com/MilesCranmer/SymbolicRegression.jl)
* [BitInformation.jl](https://github.com/milankl/BitInformation.jl)
Currently the installation of the Julia packages needs to be initiated by the user and is handled completely outside of the `conda` or `mamba` package management. The Julia feedstock configures the Julia depot within the conda prefix rather than the default `~/.julia` depot location.
It would best if these Julia packages could be directly installed by `conda` rather than having the user initiate a manual step. I have [developed a mechanism using the Julia depot stack that allows `conda` to directly install Julia packages into the user's Julia load path](https://github.com/conda-forge/pysr-feedstock/pull/43#issuecomment-1233129264) if they use a preconfigured Julia project environment. Thus we are now prepared to propose conda-forge feedstocks for individual Julia packages and now need to decide upon a naming scheme.
# Julia package naming guidelines
Julia packages typically include capitalization according to camel case and a "file extension" with a preceding period. For example:
* [PyCall.jl
](https://github.com/JuliaPy/PyCall.jl)
* [Conda.jl](https://github.com/JuliaPy/Conda.jl)
* [HDF5.jl](https://github.com/JuliaIO/HDF5.jl)
* [HDF5_jll.jl](https://github.com/JuliaBinaryWrappers/HDF5_jll.jl)
* [ClusterManagers.jl](https://github.com/JuliaParallel/ClusterManagers.jl)
* [SymbolicRegression.jl](https://github.com/MilesCranmer/SymbolicRegression.jl)
* [BitInformation.jl](https://github.com/milankl/BitInformation.jl)
Julia package naming guidelines are located at the following URL:
https://pkgdocs.julialang.org/v1/creating-packages/#Package-naming-guidelines-1
# Potential naming schemes within conda-forge
My first preference would be to preserve the original package names. Julia packages can be uniquely identified by the ".jl" extension from those in other languages.
From #18, many seem to prefer no capitalization. If we do want to conform to a language prefix with all lowercase, my preference would be "julia-" since this would be unambiguous:
* julia-pycall
* julia-conda
* julia-hdf5
* julia-hdf5_jll
* julia-clustermanagers
* julia-symbolicregression
* julia-bitinformation
I could also see an argument for using "jl-" based on brevity and similarity to the original name:
* jl-pycall
* jl-conda
* jl-hdf5
* jl-hdf5_jll
* jl-clustermanagers
* jl-symbolicregression
* jl-bitinformation
cc: @ngam, @isuruf @ocefpaf
# References
1. https://github.com/conda-forge/julia-feedstock/issues/14
2. https://github.com/conda-forge/pysr-feedstock/pull/43#issuecomment-1233129264
Beitragsleitfaden
Bewertung
Dieses Issue wurde noch nicht bewertet.