Cross platform package and package naming guidelines

Tooling Package Management
,
1

I would like to create Github-repo erjulix for a package Erjulix which makes it possible to send messages/data from Erlang/Elixir to Julia and back and call functions or eval expressions cross-platform. The functionality is doable as my local tests show.

It should be ideally one repo and one package for Julia and Elixir. Now I have to follow some conventions when naming the package directory and the Github repo:

  • the top-level package directory name must be lowercase for Elixir,
  • module names in Elixir must be capitalized and written in CamelCase
  • the Github repo should not have a .jl extension since it is not a pure Julia package.

The subdirectory structure and file naming seems to work. The Julia module would be src/Erjulix.jl, the module name in Julia and Elixir both would be Erjulix.

Now my question is: is it mandatory in Julia that

  • the GitHub repo has a .jl extension like MyPackage.jl,
  • the repo name, top-level module file name and module name must match each other (MyPackage) or can they be different,
  • Julia module names must be capitalized

or would it be sufficient as mentioned in the General README that I explain why I don’t follow those conventions?

Any other suggestions?

2

Cool project! More language interopereability is fantastic. I don’t know the specific answer to your question - I think the package manager doesn’t care about the parent directory, just that there’s a file name in src that matches the module name, and that both of those match what’s in the Project.toml, but I’m only like 60% confident.

I’m curious why a single repo is desired though - do the packages call code from one another?

1 Like
3

Mainly for simplicity and maintainability! For example, if the main application is a web server in Phoenix and wants to use Julia for stats, analysis and plotting, it may want to start a Julia session and server. This is easier if everything is in the same file tree. No, there is no shared code. Everything is done by messaging, Julia tasks and BEAM processes talking to each other via sockets.

1 Like
4

This is not required for packages in subdirectories, where it is expected that there are other constraints on the repo naming.

That is all correct.

2 Likes
5

For a somewhat similar example, I have made dual Julia/Python libraries at work with the general repo structure:

├── julia
│   ├── Project.toml
│   ├── src
│   │   └── MyPackage.jl
│   └── test
│       └── runtests.jl
├── python
│   ├── mypackage
│   │   ├── __init__.py
│   │   └── mypackage.py
│   ├── setup.py
│   └── tests
└── README.md

Being proprietary they are obviously not registered in General but in the company local registry (and in the local devpi server for the Python packages). From a technical point of view this works without a hitch.

2 Likes
6

Thank you very much. I also found the following remark in the Julia Registrator README:

Registering a package in a subdirectory

If the package you want to register is in a subdirectory of your git repository, you can tell Registrator to register it by adding the subdir argument to your trigger, e.g. `@JuliaRegistrator register subdir=path/to/my/package‘ .

But currently I have Julia, Erlang and Elixir files side by side in one structure:

erjulix
├── Project.toml
├── README.md
├── lib
│   └── erjulix.ex
├── mix.exs
├── mix.lock
├── src
│   ├── Erjulix.jl
│   ├── ejx_udp.erl
└── test
    ├── erjulix_test.exs
    ├── runtests.jl
    └── test_helper.exs

This works/compiles as an Elixir app. With your comments above this should work/register as a Julia package too. Right?

1 Like
7

Yes. The Julia package will contain all the elixir files as well, which is fine if that’s how you intend it. With this file structure it’s not a subdirectory package, so AutoMerge will complain if the repository name doesn’t have the .jl suffix. That doesn’t mean it’s not allowed but it will require some manual intervention and possibly convincing the General registry maintainers that there are good reasons for it.

Update: I was thinking erjulix was a repository name but maybe it’s a directory name. In the latter case the Julia package would indeed be a subdirectory package, inside erjulix.

1 Like
8

Thank you again. Now I created the erjulix repo. It is – again for simplicity – both repo and directory.

I will do my best to convince them :grinning:.

2 Likes