fetchFromGitHub: force re-fetch when rev changes #11
|
|
@ -8,6 +8,7 @@ lib.makeOverridable (
|
|||
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
|
||||
, deepClone ? false, private ? false, forceFetchGit ? false
|
||||
, sparseCheckout ? []
|
||||
, githubBase ? "github.com", varPrefix ? null
|
||||
, passthru ? { }
|
||||
|
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
|
||||
, meta ? { }
|
||||
, ... # For hash agility
|
||||
}@args:
|
||||
|
|
@ -21,6 +22,9 @@ let
|
|||
|
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
|
||||
else builtins.unsafeGetAttrPos "rev" args
|
||||
);
|
||||
baseUrl = "https://${githubBase}/${owner}/${repo}";
|
||||
newPassthru = passthru // {
|
||||
|
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
|
||||
inherit rev owner repo;
|
||||
|
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
|
||||
};
|
||||
|
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
|
||||
newMeta = meta // {
|
||||
homepage = meta.homepage or baseUrl;
|
||||
} // lib.optionalAttrs (position != null) {
|
||||
|
|
@ -57,16 +61,19 @@ let
|
|||
|
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
|
||||
fetcherArgs = (if useFetchGit
|
||||
then {
|
||||
inherit rev deepClone fetchSubmodules sparseCheckout; url = gitRepoUrl;
|
||||
passthru = newPassthru;
|
||||
|
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
|
||||
} // lib.optionalAttrs (leaveDotGit != null) { inherit leaveDotGit; }
|
||||
else {
|
||||
url = "${baseUrl}/archive/${rev}.tar.gz";
|
||||
|
||||
passthru = {
|
||||
|
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
|
||||
passthru = newPassthru // {
|
||||
|
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
|
||||
inherit gitRepoUrl;
|
||||
};
|
||||
}
|
||||
) // privateAttrs // passthruAttrs // { inherit name; };
|
||||
in
|
||||
|
||||
fetcher fetcherArgs // { meta = newMeta; inherit rev owner repo; }
|
||||
|
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
|
||||
(fetcher fetcherArgs).overrideAttrs (finalAttrs: previousAttrs: {
|
||||
|
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
|
||||
meta = newMeta;
|
||||
|
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
|
||||
})
|
||||
|
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
|
||||
)
|
||||
|
|
|
|||
|
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
TBH, I'd also change TBH, I'd also change `source` to something like `github-repo`, just to make it clearer in the name that the derivation comes from a GitHub checkout.
nit: nit:
```suggestion
, name ? null # Override with null to use the default value
```
Here's a slightly different proposal: append the github base url as provenance like so: Here's a slightly different proposal: append the github base url as provenance like so: `/nix/store/wzvnh3p7gv1qlqhb3iif878bfffzrvaz-source-pypa-build-refs-tags-1.1.1-github.com.drv`. That's a good self-description, leaves the `source` that people might be used to, and generalizes unambiguously to other `fetchFrom`s. We can also put it before the `owner`.
Only potential issue I see is creating some pretty long path names, but I don't see it being a massive issue. Seems fine to me. Only potential issue I see is creating some pretty long path names, but I don't see it being a *massive* issue. Seems fine to me.
|
||||
TBH, I'd also change
sourceto something likegithub-repo, just to make it clearer in the name that the derivation comes from a GitHub checkout.