search

ExpandingMan / Arrow.jl

DEPRECATED in favor of [JuliaData/Arrow.jl](https://github.com/JuliaData/Arrow.jl)
Other
56 stars 9 forks source link

major package management fuckage, may have to delete tags #32

Closed ExpandingMan closed 6 years ago

ExpandingMan commented 6 years ago

@davidanthoff @kristofferC

Hey guys, sorry about this but I seem to have done a number of things to this package which seem to have conspired to completely screw up this package, and the only alternative I can see right now would be to remove it from JuliaRegistries/General and re-register it.

So, problem the first is that somehow I managed to supply the local Project.toml with the wrong UUID. I'm not quite sure how I did this, as I was careful to use the UUID that seemed to be assigned to it, but I now suspect that when I did this I was using a local configuration that had not used the UUID's generated for JuliaRegistries/General.

Problem the second is that something got all screwed up by the tagging, I'm not quite sure what. It probably has something to do with a fact that at some point I deleted a tag, and recreated one with the same name. When I do dev Arrow in 1.0, I wind up with version 0.1.1. I am then stuck on version 0.1.1 and I cannot dev Arrow with anything newer.

So, at this point it seems that I have FUBARed things so badly that I don't see any choice but to delete all tags and remove this package from the registries, and register it again. Please let me know if you have any other ideas.

ExpandingMan commented 6 years ago

Ok, I think 0.1.1 was tagged before everything got screwed up. I'm going to try and see if I can resolve this by working from that point, so I'll re-tag now and that shouldn't affect anything.

KristofferC commented 6 years ago

Don't do anything rushed. Even if you added a project file with wrong uuid that should not have impacted how the package is listed in the registry.

You might be hitting https://github.com/JuliaLang/Pkg.jl/issues/645 which is a bug in the package manager. If you explain in detail the problem we can see if it is indeed https://github.com/JuliaLang/Pkg.jl/issues/645 that is causing your confusion.

ExpandingMan commented 6 years ago

There seems to be all sorts of strangeness, I can't really tell if it's #645.

Primarily two things: first, when I do dev Arrow (with no existing Arrow directory) it pulls this commit: a3f5b5f21900c90a1b5ca4ef61fac51dbbf81279 for no apparent reason (it wasn't even one of the tagged ones). Last night, when I did git pull origin master on Arrow and then again did dev Arrow in the package manager, it was giving me unsatisfiable requirements. Today I'm on a different machine and am currently unable to reproduce that particular result (i.e. it still pulls a bogus commit, but I'm able to do dev Arrow after pulling to latest).

What I started to do to attempt a solution is the following:

Since none of those tags will have Project.toml at all, and all of the tags I've made since I've been having problems will have been replaced I infer that the above procedure will be guaranteed to give me a working package.

(Of course in my stupidity I already made a v0.2.0 tag last night having forgotten to bump the Julia version, which mercifully now has the waiting for author tag, so I'll cancel that.)

KristofferC commented 6 years ago

dev has a bug that it might not load the latest commit, you can just git pull the latest one manually though (https://github.com/JuliaLang/Pkg.jl/issues/465).

Never delete tags that have been registered to METADATA. Don't modify the commit for existing versions registered to METADATA. Just push new tags instead.

ExpandingMan commented 6 years ago

Since they are already deleted should I proceed with what I was doing? This doesn't seem to explain why I was sometimes getting "unsatisfiable requirements" (or why I can't regularly reproduce that error, perhaps it's 645).

KristofferC commented 6 years ago

Yes it might be that issue. The best thing would be if you could retag the tags with the same commit as registered in METADATA.jl.

ExpandingMan commented 6 years ago

I'm really afraid to do that as those have bad Project.toml files. At this point I'm pretty confident that tagging these later commits will work just fine for METADATA, but I'm less confident about JuliaRegistries/General.

I'll defer to your judgment, but considering all the problems I've had it would make me feel a lot better if we were able to replace those tags with these commits where we are completely confident that there is no package management related strangeness.

ExpandingMan commented 6 years ago

Oh, actually come to think of it we really have to try retagging. In at least one of them I had accidentally uploaded my Manifest.toml before I put it in my .gitignore.

Do you think this will be ok, or will this absolutely break JuliaRegistries/General and I have to figure something else out?

(Sorry, I know my screw ups really contributed to the insanity on this.)

KristofferC commented 6 years ago

Having a Manifest in your package is totally ok :)

ExpandingMan commented 6 years ago

By the way, why are the git commit hashes that appear in METADATA completely different from those in JuliaRegistries/General? The latter don't even seem to be commit hashes at all, care to illuminate what's going on there?

KristofferC commented 6 years ago

They are tree hashes, i.e. based on the content in the repository at a snapshot instead of the history of it.

ExpandingMan commented 6 years ago

Oh wow. I noticed that you talked about that extensively in your JuliaCon talk, but I didn't realize that it meant that you can't use commit hashes.

ExpandingMan commented 6 years ago

Ok, I restored the original tags. Initially I was having the same problem, but I then deleted my entire .julia directory and now things seem restored to normal.

If I may make a suggestion, while I have no doubt that whatever happened here was primarily my fault (perhaps with the flames of my confusion stoked by some Pkg3 bugs), it does seem that it may be relatively easy for those of us uncomfortable and unfamiliar with the immutability of tagging our own packages (that's right, I seldom do it) to arrive in this sorry state; so it would be really nice if some sort of unfuck PackageName command were available. What I imagine this doing is

I'll wait until tomorrow for the dust to clear and than make my new tags based on more recent commits, with the Project.toml removed (because I am now paranoid about what that is doing).

And thanks for all your help @KristofferC !