Switching package registration systems soon

package-manager
#136

I have switched attobot back on, but it will now only tag packages which are enabled for Julia 0.6. Please open an issue if it doesn’t work, as I haven’t actually tested it.

6 Likes
#137

I tried Registrator.jl for the first time but my PR isn’t being merged: https://github.com/JuliaRegistries/General/pull/77

It looks like other PRs are merged within an hour. Is there something wrong with the way I made the PR?

#138

The merging process is manual for the moment, so the “problem” is that Stefan is sleeping I guess :slight_smile:

3 Likes
#139

Ah, that explains it. Sounds like a blast :rofl:

#140

I’m a bit confused: I tagged FillArrays.jl v0.6 using the new procedure, but this is prevented by use due to upper bounds in JuliaRegistries/General in BandedMatrices.jl (https://github.com/JuliaRegistries/General/blob/master/B/BandedMatrices/Compat.toml), LazyArrays.jl, and probably a few others. I have no idea where these upper bounds came from: they were added on 11 April by a sync from METADATA.jl, but The upper bounds aren’t present: BandedMatrices.jl only has a lower bound for FillArrays.jl (https://github.com/JuliaLang/METADATA.jl/blob/metadata-v2/BandedMatrices/versions/0.9.0/requires).

Any idea where these upper bounds came from? Any suggestion other than re-tagging everything?

#141

See Dependency problem with FIllArrays

#142

Any estimate when that might be? Any chance that a group of people could do the merging in the meantime, rather than just Stefan? Right now the last PR in General was merged more than 13 hours ago.

1 Like
#143

When we’re more confident that the results are always correct. As to more people doing merges, there are a number of people with permissions. I’ll look into making sure those who know how to review these things are aware that they can merge PRs.

7 Likes
#144

Just to provide feedback, the gen_project.jl worked flawlessly in my packages. Just download the file, enter in your package directory and run julia gen_project.jl. The resulting Project.toml was very good. I just needed to do minor modifications (license, current version, description, etc.), but it indeed saved me a lot of time. Thanks @StefanKarpinski!

I also removed the REQUIRE file, since it was not being used for my packages anymore (no support for Julia 0.6).

Finally, the process with Registrator.jl was also very easy. I do prefer the new workflow compared to what we had with attobot.

10 Likes
#145

I think the silence in this thread is a testament for how seamless the transition ended up being. Thank you @StefanKarpinski :+1:

15 Likes
#146

@Ronis_BR I ended up adapting your comment to help improve the documentation of Registrator

3 Likes
#147

If anyone package maintainer feels that dependencies of their package or on their package have been inappropriately capped and it’s causing version resolution problems, please let me know and I can make PRs like this one to fix these bounds en masse.

1 Like
Understanding an "Unsatisfiable requirements" problems
Unsatisfiable requirements for FixedEffectModels package
#148

Please do DynamicHMC:

#149

Not sure this is the same problem. I just installed the latest version of Makie and cant get it to run and am not sure what I need to do to fix it, advice would be great, error output is below:

(v1.1) pkg> test Makie
   Testing Makie
 Resolving package versions...
ERROR: Unsatisfiable requirements detected for package ImageFiltering
[6a3955dd]:
 ImageFiltering [6a3955dd] log:
 ├─possible versions are: [0.0.1-0.0.2, 0.1.0-0.1.4, 0.2.0-0.2.3,
0.3.0, 0.4.0-0.4.1, 0.5.0-0.5.4, 0.6.0] or uninstalled
 ├─restricted to versions * by GLMakie [e9467ef8], leaving only
versions [0.0.1-0.0.2, 0.1.0-0.1.4, 0.2.0-0.2.3, 0.3.0, 0.4.0-0.4.1,
0.5.0-0.5.4, 0.6.0]
 │ └─GLMakie [e9467ef8] log:
 │   ├─possible versions are: 0.0.5 or uninstalled
 │   └─GLMakie [e9467ef8] is fixed to version 0.0.5
 ├─restricted to versions 0.6.0 by an explicit requirement, leaving
only versions 0.6.0
 └─restricted by compatibility requirements with MakieGallery
[dbd62bd0] to versions: [0.0.1-0.0.2, 0.1.0-0.1.4, 0.2.0-0.2.3, 0.3.0,
0.4.0-0.4.1, 0.5.0-0.5.4] — no versions left
   └─MakieGallery [dbd62bd0] log:
     ├─possible versions are: 0.0.1-0.0.7 or uninstalled
     └─restricted to versions 0.0.6-* by an explicit requirement,
leaving only versions 0.0.6-0.0.7
#150

Not sure. @sdanisch, are there compatibility bounds issue with Makie?

#151

Just installed it from scratch and it adds just fine.
I guess you’ll need to make sure that you freed e.g. ImageFiltering and deps!

#152

It would be convenient if there was some sort of forceadd that changed dependency versions as needed. At the moment, half the time I just wipe my environment and start from scratch to achieve this.

#153

Thanks for the hard work on the package registration system.
I just wanted to release a new version of a package which runs on Julia 0.6, Julia 0.7, Julia 1.0, Julia 1.1 (yes I have still some users on Julia 0.6 which I want to support).

The compat section in Project.toml (generated by gen_project.jl) reflects this correctly:

[compat]
BinDeps = "≥ 0.4.0"
julia = "≥ 0.6.0"

However, I get the following error message from JuliaRegistrator when I try to register a new version:

Error while trying to register: Julia version < 0.7 not allowed in `[compat]`

Here is the commend thread:

Somebody has any ideas what could be wrong?

#154

You need to use the REQUIRE file and attobot to register the version for v0.6 and below. While, in the Project.toml file you need to be v0.7 and up.

2 Likes
#155

Putting julia = "0.7, 1.0" in Project.toml and julia 0.6 in REQUIRE worked for me: