juliaregistries / general Goto Github PK

Things are not as bad here as in METADATA where the README is not visible, but if we add a README to this repo, it would still show up fairly low on the site. Might be better to put all the package file in a single directory such that the root directory has relatively few files.

I am trying to perform Pkg.Registry.add("General") using a pristine Julia 1.1.1 distribution in Docker (from amazonlinux:2). It seems there are two branches register/secp256k1 and register/Secp256k1, which are causing a name collision in git clone and preventing adding the General registry. This means I cannot add any package, and as a result am completely blocked from using Julia. It seems like this would affect everyone. Probably the resolution will be to remove the register/secp256k1 branch by someone with write access to the repository.

[ Info: registry status
Registry Status
(no registries found)
[ Info: registry add General
Cloning registry from "https://github.com/JuliaRegistries/General.git"
ERROR: LoadError: ArgumentError: '/var/package/depot/registries/General/.git/logs/refs/remotes/origin/register/secp256k1' exists. force=true is required to remove '/var/package/depot/registries/General/.git/logs/refs/remotes/origin/register/secp256k1' before copying.
Stacktrace:
[1] #checkfor_mv_cp_cptree#10(::Bool, ::Function, ::String, ::String, ::String) at ./file.jl:293
[2] #checkfor_mv_cp_cptree at ./none:0 [inlined]
[3] #cptree#11(::Bool, ::Bool, ::Function, ::String, ::String) at ./file.jl:302
[4] #cptree at ./none:0 [inlined]
[5] #cptree#11(::Bool, ::Bool, ::Function, ::String, ::String) at ./file.jl:309
[6] #cptree at ./none:0 [inlined]
[7] #cptree#11(::Bool, ::Bool, ::Function, ::String, ::String) at ./file.jl:309
[8] #cptree at ./none:0 [inlined]
[9] #cptree#11(::Bool, ::Bool, ::Function, ::String, ::String) at ./file.jl:309
[10] #cptree at ./none:0 [inlined]
[11] #cptree#11(::Bool, ::Bool, ::Function, ::String, ::String) at ./file.jl:309
[12] #cptree at ./none:0 [inlined]
[13] #cptree#11(::Bool, ::Bool, ::Function, ::String, ::String) at ./file.jl:309
[14] #cptree at ./none:0 [inlined]
[15] #cptree#11(::Bool, ::Bool, ::Function, ::String, ::String) at ./file.jl:309
[16] #cptree at ./none:0 [inlined]
[17] #cptree#11(::Bool, ::Bool, ::Function, ::String, ::String) at ./file.jl:309
[18] #cptree at ./none:0 [inlined]
[19] #cp#12(::Bool, ::Bool, ::Function, ::String, ::String) at ./file.jl:334
[20] cp(::String, ::String) at ./file.jl:330
[21] clone_or_cp_registries(::Pkg.Types.Context, ::Array{Pkg.Types.RegistrySpec,1}, ::String) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Types.jl:1131
[22] clone_or_cp_registries at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Types.jl:1090 [inlined]
[23] add at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Registry.jl:28 [inlined]
[24] add at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Registry.jl:27 [inlined]
[25] add(::Array{String,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Registry.jl:26
[26] add(::String) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Registry.jl:25
[27] top-level scope at none:0
[28] include at ./boot.jl:326 [inlined]
[29] include_relative(::Module, ::String) at ./loading.jl:1038
[30] include(::Module, ::String) at ./sysimg.jl:29
[31] exec_options(::Base.JLOptions) at ./client.jl:267
[32] _start() at ./client.jl:436
in expression starting at /var/scripts/package.jl:18

These guidelines are intended not as requirements for packages but as very conservative guidelines, which, if your new package or new version of a package meets them, it may be automatically merged.

New package

1. Normal capitalization
   • name should match r"^[A-Z]\w*[a-z][0-9]?$"
     • i.e. starts with a capital letter, ASCII alphanumerics only, ends in lowercase
2. Not too short
   • at least five letters
     • you can register names shorter than this, but doing so requires someone to approve
3. Standard initial version number
   • one of 0.0.1, 0.1.0, 1.0.0
4. Repo URL ends with /$name.jl.git where name is the package name

New version

1. Sequential version number
   • if the last version was 1.2.3 then the next can be 1.2.4, 1.3.0 or 2.0.0
2. Compat for all dependencies
   • all [deps] should also have [compat] entries (and Julia itself)
   • [compat] entries should have upper bounds
3. Version can be installed
   • given the proposed changes to the registry, can we resolve and install the new version of the package?
4. Version can be loaded
   • once it's been installed (and built?), can we load the code?

FinEtools: release at v3.0.0, registry has v2.0.1.
https://github.com/PetrKryslUCSD/FinEtools.jl/releases

Perhaps the repo is not set up correctly with Julia Team Registrator? This is what I have:

I've released the new version for about 2 days, while the synchronization haven't been performed yet.

The repo is at https://github.com/thautwarm/MLStyle.jl

incorrect files are installed in the .julia directory when using Pkg.add("MAT")
I had to clone https://github.com/JuliaIO/MAT.jl and replace the file in .julia/packages directory in order to get it to precompile successfully and work.

oops.

Hello,

I would like to change the url of the package EnKF.jl (reference of the pull request #2801) to:
https://github.com/mleprovost/EnKF.jl but I can't do it with Registrator

Best,

Hey all, I get the below message. How do I add a compat entry to my project file?

Your new package pull request does not meet the following guidelines for auto-merging:

The following dependencies do not have a compat entry that has an upper bound: CodecZlib, HTTP, JSON, Revise
Note that the guidelines are only required for the pull request to be merged automatically. However, it is strongly recommended to follow them, since otherwise the pull request needs to be manually reviewed and merged by a human.

I would like to migrate some package that are already registered in the registry to a GitHub organization I've just created. I couldn't find the steps in the README FAQ, could you please confirm that I can just proceed with the normal GitHub steps to migrate, and then later submit a PR here to update the URL?

The latest version of JSON.jl was tagged, but it's broken on Julia 0.7 (ref) yet it still lists support for Julia 0.7 in its compat section here: https://github.com/JuliaRegistries/General/pull/2060/files#diff-68074356855d5796422b09f38b90317fR41. This has caused failures for us over on Compose.jl and Gadfly.jl (ref)

Can this be fixed retroactively such that Julia 0.7 support is dropped from JSON v0.21?

I figure we might as well automate as much of the General registry maintenance as possible.

What do y'all think about installing the probot-stale app on the General registry? That way, registry maintainers wouldn't need to manually close stale PR's (e.g. PR's in which an author reply is requested, and the author never replies).

I've been pulling my hair out the past two hours because all of a sudden packages will not update, install, resolve, remove, anything...

I keep getting this error when using Pkg3:
restricted by julia compatibility requirements to versions: uninstalled — no versions left

When I inspected the Compat.toml of the offending packages, I saw that indeed, packages which had been working on 0.7/1.0 were now only accepting julia 0.6.

Then I noticed the most recent commit 0c75a4d, which made this change, intentionally?

So what am I supposed to do? I can no longer use the package manager. Am I not using pkg3 correctly, or is this a bug?

Hi, I might be wrong but there are uuids used in dependencies that do not have a corresponding package, is this expected? I found those that are actually referred (if my script is right) by the highest package version. Like N/NetworkLearning/Versions.toml containing "0.1.0", N/NetworkLearning/Deps.toml containing Future "9fa8497b-333b-5362-9e8d-4d0656e87820", but this package does not exists:

• 2a0f44e-6c83-55bd-87e4-b1978d98bd5f
• b77e0a4c-d291-57a0-90e8-8db25a27a240
• 8bf52ea8-c179-5cab-976a-9e18b702a9bc
• a63ad114-7e13-5084-954f-fe012c677804
• 37e2e46d-f89d-539d-b4ee-838fcccc9c8e
• 8bb1440f-4735-579b-a4ab-409b98df4dab
• 2f01184e-e22b-5df5-ae63-d93ebab69eaf
• 7b1f6079-737a-58dc-b8bc-7a2ca5c1b5ee
• 8dfed614-e22c-5e08-85e1-65c5234f0b40
• de0858da-6303-5e67-8744-51eddeeeb8d7
• 44cfe95a-1eb2-52ea-b672-e2afdf69b78f
• 8ba89e20-285c-5b6f-9357-94700520ee1b
• 9abbd94-dff8-562f-b5e8-e1ebf5ef1b79
• 1a1011a3-84de-559e-8e89-a11a2f7dc383
• 9a3f828-a2c9-5f02-9a11-845980a1fd5c
• 8f399da3-3557-5675-b5ff-fb832c97cbdb
• 4ec0a83e-493e-50e2-b9ac-8f72acf5a8f5
• de555fa4-b82f-55e7-8b71-53f60bbc027d
• 6462fe0b-24de-5631-8697-dd941f90decc
• 9fa8497b-333b-5362-9e8d-4d0656e87820

Since so many users rely on the General registry, it would be nice to increase the level of security.

I don't think that it is feasible to ask all users that make manual PRs to General to GPG-sign their commits.

I do think, however, that is it reasonable for the two main bot users that generate automated PRs to General (@JuliaRegistrator and @jlbuild) to GPG-sign their automatically generated commits.

Related issues:

• JuliaRegistries/Registrator.jl#273
• JuliaPackaging/Yggdrasil#635

#7046

To register WebIO v0.8.13 (lucky number 13!), I added JSExpr to the compat because I was trying to fix an issue where JSExpr v1 has just been released and was incompatible.

The merge bot yelled at me because I didn't have compat for other things so I decided to also add everything else. However, it looks like when I re-triggered the merge bot, it lost the compat entry for JSExpr?

JSExpr v0.5 depends on WebIO, but in v1.0, we dropped the dependency (and were planning on reversing it for WebIO v1.0). I forgot that WebIO doesn't actually depend on JSExpr though when I added the compat entry.

The registrator bot should probably(?) yell at me because JSExpr is not a dependency of WebIO (which I discovered with #7145).

@ChrisRackauckas, this is related to: dea440d

This is the first project where the repo name doesn't match the directory name. I realize that the project was a rename fork, but it might screw up bots in the future?

Hey there,
I'm having an issue adding Julia to anaconda. After downloading I give the commands;

using Pkg
Pkg.add("IJulia")

It seems like it will download but then it smacks me with this error. I have tried running the executable as administrator but I have not had any luck.

I'd like to move GenomicVectors.jl over to BioJulia. How might I un-register it here?

I would like to rename my package ClustForOpt to TimeSeriesClustering. https://github.com/holgerteichgraeber/TimeSeriesClustering.jl

However, JuliaRegistrator gives me the following when I do @JuliaRegistrator register:
Error while trying to register: Changing package names not supported yet .

What should I do to rename my package?

This is a crossreference of the same issue in JuliaRegistrator: JuliaRegistries/Registrator.jl#211

Not able to register a release for ArrayFire because it has been moved from
https://github.com/JuliaComputing/ArrayFire.jl to https://github.com/JuliaGPU/ArrayFire.jl

"Error while trying to register: Changing package repo URL not allowed"

Old URL redirects to a new location, so it should be possible to detect and update package repo URL automatically.

@dlfivefifty, these bounds on your packages look suspicious:

A/ApproxFunBase/Compat.toml
32-["0.0.4"]
33:julia = "0.7-1.1"

A/ApproxFunFourier/Compat.toml
27-["0.0.2-0"]
31:julia = "0.7-1.1"

A/ApproxManifoldProducts/Compat.toml
14-["0.0.2-0"]
16:julia = "0.7-1.1"

Can you confirm or deny that these should be changed to 0.7-1?

As of the last commit (6595025 @StefanKarpinski ) performing an update in the package manager results in Unsatisfiable requirements detected for package ... for nearly all packages.
For anybody encountering this, I was able to git checkout the General repository at the commit before it and it now functions as expected.

I was slightly surprised that I tagging new patches for previous versions is not auto-merged, e.g., tagging v0.6.1 after v0.7:

#5751

This seems like a very "normal" situation where, for whatever reason, older versions need to be maintained, in fact Julia does it as well (v1.0.5 tagged after v1.1 for example). This isn't the case for me, but one could imagine that this might arise from security bug fixes, in which case rapid merging would be ideal.

I'd propose changing auto-merge to allow for older tags, perhaps under the condition that the tag is on a separate branch to master, e.g., the tag above was on the branch release-0.6.

Recently a medium post outlined how a security researcher was able to obtain commit credentials to the homebrew repository in a surprisingly short amount of time.

https://medium.com/@vesirin/how-i-gained-commit-access-to-homebrew-in-30-minutes-2ae314df03ab

Is this registry appropriately protected against these sorts of problems? Is there any work that needs to be done to make things safer?

Hello, there is a version of OpenCL which is compatible with Julia version > 0.7.0 (i.e. 1.0.0, and 1.1.0). Is the version that the package manager install specified here? Pkg now only get those earlier versions, where there are syntax changes that breaks it.

This is a fairly minor issue but in, for example,

https://github.com/JuliaRegistries/General/blob/master/A/ApproxFun/Compat.toml

the versions "0.10.x" are listed before "0.2.x", which is slightly confusing.

I moved my package from https://github.com/tkf/ProgressMeterLogging.jl to https://github.com/tkf/ConsoleProgressMonitor.jl and re-registered it with a different UUID. ProgressMeterLogging is still installable presumably because github redirects the old repository to the new one. I renamed old tags so the old release of ProgressMeterLogging.jl is "rooted" (and it's accessible via ConsoleProgressMonitor#master anyway).

But are there any other actions I should take after re-registration? In particular:

• Should I re-create the old repository (https://github.com/tkf/ProgressMeterLogging.jl) with all the releases? (and maybe archive it afterward.)

• Is there any recommended way to discourage people from installing the old package? Ideally, Pkg.add should fail and it should not be listed in pkg.julialang.org (although it looks like it hasn't been updated for a while ATM). An approximation I can implement is to recommend installing the new package via @error in __init__ of the old package.

As Chris (and others) have mentioned, the registry is currently broken. New package versions are not installable. I noticed this with MusicManipulations which was tagged days ago but still not installable on Travis or anywhere else. Other authors, e.g. DiffEq, Measurements.jl have the same problem.

DeIdentification was registered a couple months ago (PR), but hasn't synced to the General registry. Is there something incorrect with the package that I need to fix?

Hello, just registered a package and now it has automatic sync with METADATA.

The package contains Project.toml with

[deps]
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"

but in the following registry doesn't have the Deps.toml file for that package.
https://github.com/JuliaRegistries/General/tree/master/J/Jive

Compat.toml
Package.toml
Versions.toml

I don't know how could I make the Deps.toml file.
It's best appreciate for any hint.
thanks.

Even if a package has a Project.toml with an uuid field, a new (apparently random, unrelated) one seems to be generated by the pipeline.

It would be nice to just use the existing one.

Cf discussion

Currently, the official stance is that the automerge guidelines are simply guidelines. They are strongly recommended, but they are not required.

On a regular basis, registry maintainers (including myself) go through the list of open pull requests and manually merge pull requests that do not adhere to the automerge guidelines.

I think that we should convert some (or all) of the automerge guidelines into hard requirements.

Here are the current automerge guidelines. Which ones should we convert into hard requirements, and which ones should stay as guidelines?

Guidelines for all registrations:

1. Version can be installed, i.e. Pkg.add("Foo") works
2. Version can be loaded, i.e. import Foo works

Guidelines only for registrations of new packages:

1. Normal capitalization
2. At least five letters long
3. Standard initial version number
4. Repo URL ends with /$name.jl.git where name is the package name

Guidelines only for registrations of new versions of existing packages:

1. Version number does not skip versions
2. Upper-bounded compat entries for all dependencies (including Julia)

Now of course I am biased. I think we should just convert all the guidelines into requirements and call it a day. But I know that not everyone will agree with that.

Now that upper bounds are getting to be commonplace, it may be worth contemplating propagating the bounds to earlier versions. I am aware that this is scary, but so is not doing it: JuliaGraphics/ColorTypes.jl#143

So based on the text below, does this mean I should push to the original branch with the updated criteria to auto-merge? Or do I need to re-do the whole process? I think this could be more clear.

Note that the guidelines are only required for the pull request to be merged automatically. However, it is strongly recommended to follow them, since otherwise the pull request needs to be manually reviewed and merged by a human.

See JuliaRegistries/TagBot#3 for tag-bot issue.

Because the commit hash is not updated when register() is called to fix a commit, tag-bot does not tag the correct commit.

I like the idea of using only squash merges in the General registry. It makes reading the commit history much easier.

Automerge now exclusively uses squash merge. However, humans that perform manual merges still have the option of selecting a merge type when they use the big green button?

Should we disable regular merges and rebase merges in the repo settings? Then all merges will be squash merges.

E.g., #7815. It doesn't seem easy to determine what this period is.

beacon-biosignals/ElectronTests.jl@0f40b67#commitcomment-37035716

I already did change the URL:

https://github.com/JuliaRegistries/General/blob/master/E/ElectronTests/Package.toml

Did I mess it up, or what's going on?

Following folders (And the relevant toml’s) are present in the registry, but the relevant package entry is not present in Registry.toml , so users cannot install these packages

• Arduino = https:/github.com/JuliaRegistries/General/tree/master/A/Arduino
• Chunks = https:/github.com/JuliaRegistries/General/tree/master/C/Chunks
• ControlCore = https:/github.com/JuliaRegistries/General/tree/master/C/ControlCore
• DotOverloading = https:/github.com/JuliaRegistries/General/tree/master/D/DotOverloading
• DynamicalBilliardsPlotting = https:/github.com/JuliaRegistries/General/tree/master/D/DynamicalBilliardsPlotting
• GetC = https:/github.com/JuliaRegistries/General/tree/master/G/GetC
• GLUT = https:/github.com/JuliaRegistries/General/tree/master/G/GLUT
• KeyedTables = https:/github.com/JuliaRegistries/General/tree/master/K/KeyedTables
• LazyCall = https:/github.com/JuliaRegistries/General/tree/master/L/LazyCall
• LazyContext = https:/github.com/JuliaRegistries/General/tree/master/L/LazyContext
• LazyQuery = "https:/github.com/JuliaRegistries/General/tree/master/L/LazyQuery"
• NanoTimes = https:/github.com/JuliaRegistries/General/tree/master/N/NanoTimes
• OnlineMoments = "https:/github.com/JuliaRegistries/General/tree/master/O/OnlineMoments"
• OpenGL = "https:/github.com/JuliaRegistries/General/tree/master/O/OpenGL"
• OrthogonalPolynomials = https:/github.com/JuliaRegistries/General/tree/master/O/OrthogonalPolynomials
• Parts = https:/github.com/JuliaRegistries/General/tree/master/P/Parts
• PhasedArrayTracking = https:/github.com/JuliaRegistries/General/tree/master/P/PhasedArrayTracking
• ProjectiveDictionaryPairLearning = https:/github.com/JuliaRegistries/General/tree/master/P/ProjectiveDictionaryPairLearning
• React = https:/github.com/JuliaRegistries/General/tree/master/R/React
• RecurUnroll = https:/github.com/JuliaRegistries/General/tree/master/R/RecurUnroll
• RequirementVersions = "https:/github.com/JuliaRegistries/General/tree/master/R/RequirementVersions"
• SDL = https:/github.com/JuliaRegistries/General/tree/master/S/SDL
• SessionHacker = https:/github.com/JuliaRegistries/General/tree/master/S/SessionHacker
• SimilarReferences = https:/github.com/JuliaRegistries/General/tree/master/S/SimilarReferences
• Sparrow = https:/github.com/JuliaRegistries/General/tree/master/S/Sparrow
• StringArrays = https:/github.com/JuliaRegistries/General/tree/master/S/StringArrays
• TypedBools = https:/github.com/JuliaRegistries/General/tree/master/T/TypedBools
• ValuedTuples = https:/github.com/JuliaRegistries/General/tree/master/V/ValuedTuples
• ZippedArrays = https:/github.com/JuliaRegistries/General/tree/master/Z/ZippedArrays

#8132 (name capitalization issue)

The newly introduced cap seems too harsh! For example I use the UnalignedVectors package in Julia 1.0 without any problems, but suddenly I just cannot install it: ERROR: LoadError: Unsatisfiable requirements detected for package UnalignedVectors [f306ff79]. And I cannot find a way to ignore this error and proceed with installation, as I know that this package works completely fine.

This is a single example, and I'm sure there are many other cases.

I am about to convert skeleton.jl, a script that generates package skeletons, to a package itself, and plan to register it.

Should I

1. just capitalize to Skeleton,
2. consider keeping the lowercase skeleton,
3. or change to something more descriptive, eg PkgSkeleton?

(I hope it is OK to ask things like this here, would prefer to make these decisions now instead of after a registration attempt).

by the influence of net, i can't download the IJulia pkg, can i regist offline?

This could clarify both

• what the General registry is, how one is expected to interact with it as a package developer (i.e. Registrator, optionally TagBot, but also you can make PRs to edit files directly)
• how to do a few things beyond tagging a new release e.g. how do I rename a package? How do I "blacklist" a version?

Hi, I registered VTKView.jl , which will have several serious binary dependencies which will take some time to become stable. So I continue to develop the package complex in my own registry. The idea is to transfer things here at a certain point of time. In order to avoid confusion I think it would be better to remove it here. Would this be possible ?