fetchFromGitHub: force re-fetch when rev changes #11
|
|
@ -1,7 +1,9 @@
|
|||
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.
|
||||
{ lib, fetchgit, fetchzip }:
|
||||
|
||||
lib.makeOverridable (
|
||||
{ owner, repo, rev, name ? "source"
|
||||
|
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.
|
||||
{ owner, repo, rev
|
||||
|
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.
|
||||
, name ? null # Override with null to use the default value
|
||||
|
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.
|
||||
, pname ? "source-${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.
|
||||
, fetchSubmodules ? false, leaveDotGit ? null
|
||||
|
`/nix/store/f291banfgj2vjz1qsvmpm09awn2gl4pj-source-github.com-pypa-build-refs-tags-1.1.1.drv` wdyt @Sorixelle ?
|
||||
, deepClone ? false, private ? false, forceFetchGit ? false
|
||||
, sparseCheckout ? []
|
||||
|
|
@ -11,6 +13,8 @@ lib.makeOverridable (
|
|||
|
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.
|
||||
}@args:
|
||||
|
||||
let
|
||||
name = if args.name or null != null then args.name
|
||||
|
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 "${pname}-${rev}";
|
||||
|
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.
|
||||
|
||||
position = (if args.meta.description or null != null
|
||||
then builtins.unsafeGetAttrPos "description" args.meta
|
||||
|
|
|
|||
|
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.