disruptek / nimph Goto Github PK

This might be another place to use the effect system.

This might be annoying in some degraded projects, but it seems like the right thing to do.

Trivial once #41 is implemented.

I guess if our computed $NIMBLE_DIR doesn't exist, we had better not pass it to Nimble... Ever.

It would be nice to be able to push upstream, or to auto-add a github remote.

Do we need to switch to checkout semantics?

Seems like we aren't peeling requirements correctly, or they are only being peeled in one direction?

The API for GitLab is being generated with OpenAPI, I just need to add signing.

/cc @Clyybber

• write a test
• write a fix

Just a track of libgit2/libgit2#3058 and libgit2/libgit2#5254, which we'll need before supporting native shallow clones.

Thankfully, this is pretty rare, but we have to decide how to handle a version like 2.1 -- is it identical to '2.1.0' for our wildcard requirements calculations?

Related to #21.

• username?
• compiler hash
• timestamp

Harder than it should be due to libgit2/libgit2#3041 but, to be honest, not much harder. We still have to look at all changes to the package definition and then either pull the patched blob out of git or just roll to it and knowVersion, so we're still iterating over every commit that touches the package file.

We should just sort them in git-land before they are added to the tag table.

...versus simple strings.

$ cd myproject
$ nimph roll 1.2.3
myproject now at tag 1.2.3
$ nimph roll npeg 0.21.3
dependency npeg now at tag 0.21.3

Maybe it should just be called point.

IIRC, this has to be done by spawning a new shell in the target directory...?

Probably something to preserve only the last X lockers?

Nimble sometimes writes empty URLs into nimblemeta.json. 🤦‍♂️

We should probably try to determine the desired package using dependencies first (ie. import names), then the official packages (tags? package names?), and finally passing to GitHub search.

Maybe make this a toggle until it's not surprising us anymore.

Distributions are bare repositories tar'd up and immutable with a "good enough" hash. They may be installed via checkout, but we might come up with a way to bless them beyond git.

We are probably going to have to implement these in Nimble if we want them to be useful in public projects.

cc @genotrance

Probably just an option to the nurse for extra log output. We need this because dependency problems are currently needlessly difficult to isolate.

We could even check to see if you have commit access to each requirement and setup ssh remotes for those you can write to.