Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Towards 1.0 - breaking changes #30

Open
GunnarFarneback opened this issue Apr 3, 2021 · 3 comments
Open

Towards 1.0 - breaking changes #30

GunnarFarneback opened this issue Apr 3, 2021 · 3 comments

Comments

@GunnarFarneback
Copy link
Owner

GunnarFarneback commented Apr 3, 2021

Going forward I'd like to make some changes, some of which need to be breaking. This issue is intended to announce what's coming up and giving a chance to discuss it.

To begin with this is what I want to achieve:

  • Registries can be downloaded from package servers instead of being cloned from git. LocalRegistry should be able to make an own clone of the registry if the one in DEPOT/registries is not a git clone. Implemented in Support registering with a temporary git clone and on a specific branch. #47.
  • Better support for using LocalRegistry from CI pipelines. This requires some configurability to allow reregistering the same version to do nothing instead of giving an error, cloning separate copies of the registry (like above), and registering on custom branches. Implemented in Support registering with a temporary git clone and on a specific branch. #47.
  • Make it practical to register packages in General. This is not the main focus of LocalRegistry but I'd like to have it as an option since the workflow is fairly different from Registrator and JuliaHub.
  • Simplify the interactive registration further to allow, in typical cases,
julia --project=<path_to_package>
using LocalRegistry
register()

both for registration of new versions and new packages. The latter requires that exactly one registry is installed besides General. First part implemented by #32, second part by #35. Extended further in #47 to also register a package in the current directory if the active project is not a package.

The necessary breaking changes identified so far are:

Further incoming breaking changes will be added to this list.

@GunnarFarneback
Copy link
Owner Author

This requires some configurability to allow reregistering the same version to do nothing instead of giving an error

I'm inclined to just make reregistration not give an error at all, only explain that it's not going to perform a registration.

@CiaranOMara
Copy link

On the subject of reregistration. When testing initial package development locally, I frequently want to reregister v0.1.0 until I'm ready to go public. It would help me if there were a way to force registration.

@GunnarFarneback
Copy link
Owner Author

I'm not going to make it convenient to change anything that has already been entered into the registry; that goes counter to the whole idea of the Julia registries. Of course you can do anything you want with your own registry so make a script which combines a git reset with a call to register if you must. Otherwise the usual workflow is to Pkg.develop the package while developing it, or Pkg.add the development branch if that fits better. Or just step through 0.0.x versions until you're ready for 0.1.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants