juliaregistries / general Goto Github PK
View Code? Open in Web Editor NEWThe official registry of general Julia packages
Home Page: https://github.com/JuliaRegistries/General/blob/master/README.md
License: MIT License
The official registry of general Julia packages
Home Page: https://github.com/JuliaRegistries/General/blob/master/README.md
License: MIT License
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?
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.
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.
r"^[A-Z]\w*[a-z][0-9]?$"
0.0.1
, 0.1.0
, 1.0.0
/$name.jl.git
where name
is the package name1.2.3
then the next can be 1.2.4
, 1.3.0
or 2.0.0
[deps]
should also have [compat]
entries (and Julia itself)[compat]
entries should have upper boundsbeacon-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?
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).
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 ?
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
by the influence of net, i can't download the IJulia pkg, can i regist offline?
E.g., #7815. It doesn't seem easy to determine what this period is.
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:
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.
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 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.
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 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
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
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?
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 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).
oops.
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
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
@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?
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:
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
.
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
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.
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.
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.
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 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.
This could clarify both
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,
@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
?
I am about to convert skeleton.jl, a script that generates package skeletons, to a package itself, and plan to register it.
Should I
Skeleton
,skeleton
,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).
I'd like to move GenomicVectors.jl over to BioJulia. How might I un-register it here?
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?
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.
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.
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.
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?
#8132 (name capitalization issue)
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.
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.
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:
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:
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?
Pkg.add("Foo")
worksimport Foo
works/$name.jl.git where name is the package name
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.