conda-forge / conda-forge/conda-forge.github.io

Package naming policies for Julia packages

Abierto
#1,822 28 comentarios 3 reacciones 0 asignados Ver en GitHub
question
Lenguaje dominante
JavaScript
Estrellas
170
Forks
320
Merge medio
2 d 10 h
PR fusionados (30 d)
5

Descripción

### 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

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.