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

Package naming policies for Julia packages

Open
#1,822 28 comments 3 reactions 0 assignees View on GitHub
question
Dominant language
JavaScript
Stars
170
Forks
320
Avg merge
2d 10h
Merged PRs (30d)
5

Description

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

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.