Re: [new] Nickel configuration language
On Mon, Mar 04, 2024 at 02:32:18PM -0800, Evan Silberman wrote: > Bump, naddy's tapping his watch Port-wise OK kn if anyone thinks so as well and wants to import...
Re: [new] Nickel configuration language
Evan Silberman wrote: > Klemens Nanni wrote: > > No idea about nickel, but port-wise this this looks fine and builds. > > > > Tests do not compile and thus don't run, though, is that a known issue? > > I think it's because dev/test dependencies are only in Cargo.toml in the > root of upstream's monorepo as workspace dependencies, e.g. for me just > now the test build failed due to an undeclared crate `tempfile`, which > is in the workspace dependencies but not declared as a dev-dependency by > nickel-lang-cli. Since we're building from the published crate artifact > and not a monorepo checkout we would have to resort to contrivances to > get any test dependencies in place and build the test. So, the issue is > known to us and probably is not a pressing issue for upstream. Seems > like an edge case as to whether NO_TEST=Yes is appropriate. > > Evan Bump, naddy's tapping his watch Evan nickel.tar.gz Description: GNU Zip compressed data
Re: [new] Nickel configuration language
Evan Silberman wrote: > Klemens Nanni wrote: > > No idea about nickel, but port-wise this this looks fine and builds. > > > > Tests do not compile and thus don't run, though, is that a known issue? > > I think it's because dev/test dependencies are only in Cargo.toml in the > root of upstream's monorepo as workspace dependencies, e.g. for me just > now the test build failed due to an undeclared crate `tempfile`, which > is in the workspace dependencies but not declared as a dev-dependency by > nickel-lang-cli. Since we're building from the published crate artifact > and not a monorepo checkout we would have to resort to contrivances to > get any test dependencies in place and build the test. So, the issue is > known to us and probably is not a pressing issue for upstream. Seems > like an edge case as to whether NO_TEST=Yes is appropriate. > > Evan Ping, reattaching unmodified since last week. Evan nickel.tar.gz Description: GNU Zip compressed data
Re: [new] Nickel configuration language
Klemens Nanni wrote: > On Fri, Feb 16, 2024 at 03:15:02PM -0800, Evan Silberman wrote: > > Stuart Henderson wrote: > > > On 2023/09/25 22:25, Evan Silberman wrote: > > > > Hi ports, > > > > > > > > Here's a port of Nickel (https://nickel-lang.org/), a programmable > > > > configuration language that allows both strong-typing and more dynamic > > > > contract-driven specification of configurations. > > > > > > > > There doesn't seem to be a uniform approach to building ports of > > > > applications that happen to be distributed as Rust crates; I'm just > > > > using the cargo index as SITES here. > > > > > > That approach seema reasonable to me. > > > > > > Two things I noticed: > > > > > > - see line 1 of crates.inc > > > - LIB_DEPENDS is not valid unless there's a WANTLIB coming from that > > > port - there should be an error message due to this when running "make > > > package", it's explained in bsd.port.mk(5) > > > > Got back to this this week and this turned out to be a bit of a rabbit > > hole. I originally added oniguruma when a crate build failed without it > > but when I looked recently I realized that the final exe didn't link to > > libonig. I followed the Cargo.toml trail a bit and determined that > > oniguruma was required by an optional feature of nickel's direct > > dependency comrak which nickel doesn't actually use. It seems like > > upstream intended to build comrak without that feature but "features = > > []" in Cargo.toml is evidently not the same as "default-features = > > false". In any case, the patches in this tarball prevent the onig crate > > from being built uselessly, and then add a feature requirement to a > > dependency directly that was previously being relied upon indirectly. > > I'll try to upstream that but I wanted to get the port out for review > > first. > > Disabling the unused feature seems like th right approach. > A brief patch comment explaining that would help, otherwhise it is > entirely unclear to porters reading just the patch, imho. Reattached with comments added to the patches. > No idea about nickel, but port-wise this this looks fine and builds. > > Tests do not compile and thus don't run, though, is that a known issue? I think it's because dev/test dependencies are only in Cargo.toml in the root of upstream's monorepo as workspace dependencies, e.g. for me just now the test build failed due to an undeclared crate `tempfile`, which is in the workspace dependencies but not declared as a dev-dependency by nickel-lang-cli. Since we're building from the published crate artifact and not a monorepo checkout we would have to resort to contrivances to get any test dependencies in place and build the test. So, the issue is known to us and probably is not a pressing issue for upstream. Seems like an edge case as to whether NO_TEST=Yes is appropriate. Evan nickel.tar.gz Description: GNU Zip compressed data
Re: [new] Nickel configuration language
On Fri, Feb 16, 2024 at 03:15:02PM -0800, Evan Silberman wrote: > Stuart Henderson wrote: > > On 2023/09/25 22:25, Evan Silberman wrote: > > > Hi ports, > > > > > > Here's a port of Nickel (https://nickel-lang.org/), a programmable > > > configuration language that allows both strong-typing and more dynamic > > > contract-driven specification of configurations. > > > > > > There doesn't seem to be a uniform approach to building ports of > > > applications that happen to be distributed as Rust crates; I'm just > > > using the cargo index as SITES here. > > > > That approach seema reasonable to me. > > > > Two things I noticed: > > > > - see line 1 of crates.inc > > - LIB_DEPENDS is not valid unless there's a WANTLIB coming from that > > port - there should be an error message due to this when running "make > > package", it's explained in bsd.port.mk(5) > > Got back to this this week and this turned out to be a bit of a rabbit > hole. I originally added oniguruma when a crate build failed without it > but when I looked recently I realized that the final exe didn't link to > libonig. I followed the Cargo.toml trail a bit and determined that > oniguruma was required by an optional feature of nickel's direct > dependency comrak which nickel doesn't actually use. It seems like > upstream intended to build comrak without that feature but "features = > []" in Cargo.toml is evidently not the same as "default-features = > false". In any case, the patches in this tarball prevent the onig crate > from being built uselessly, and then add a feature requirement to a > dependency directly that was previously being relied upon indirectly. > I'll try to upstream that but I wanted to get the port out for review > first. Disabling the unused feature seems like th right approach. A brief patch comment explaining that would help, otherwhise it is entirely unclear to porters reading just the patch, imho. No idea about nickel, but port-wise this this looks fine and builds. Tests do not compile and thus don't run, though, is that a known issue?
Re: [new] Nickel configuration language
Stuart Henderson wrote: > On 2023/09/25 22:25, Evan Silberman wrote: > > Hi ports, > > > > Here's a port of Nickel (https://nickel-lang.org/), a programmable > > configuration language that allows both strong-typing and more dynamic > > contract-driven specification of configurations. > > > > There doesn't seem to be a uniform approach to building ports of > > applications that happen to be distributed as Rust crates; I'm just > > using the cargo index as SITES here. > > That approach seema reasonable to me. > > Two things I noticed: > > - see line 1 of crates.inc > - LIB_DEPENDS is not valid unless there's a WANTLIB coming from that > port - there should be an error message due to this when running "make > package", it's explained in bsd.port.mk(5) Got back to this this week and this turned out to be a bit of a rabbit hole. I originally added oniguruma when a crate build failed without it but when I looked recently I realized that the final exe didn't link to libonig. I followed the Cargo.toml trail a bit and determined that oniguruma was required by an optional feature of nickel's direct dependency comrak which nickel doesn't actually use. It seems like upstream intended to build comrak without that feature but "features = []" in Cargo.toml is evidently not the same as "default-features = false". In any case, the patches in this tarball prevent the onig crate from being built uselessly, and then add a feature requirement to a dependency directly that was previously being relied upon indirectly. I'll try to upstream that but I wanted to get the port out for review first. Evan nickel.tar.gz Description: GNU Zip compressed data
Re: [new] Nickel configuration language
Le lundi 25 septembre 2023 à 22:25 -0700, Evan Silberman a écrit : > Hi ports, > > Here's a port of Nickel (https://nickel-lang.org/), a programmable > configuration language that allows both strong-typing and more dynamic > contract-driven specification of configurations. > > There doesn't seem to be a uniform approach to building ports of > applications that happen to be distributed as Rust crates; I'm just > using the cargo index as SITES here. > > Not hopping on MAINTAINER at this time, but maybe later. > > Evan thanks! As you used crates, it's really different than my port submission I sent a while ago, but it should be easier to maintain. however, "make test" fails, I'm not sure why though, maybe some missing crates?
Re: [new] Nickel configuration language
On 2023/09/25 22:25, Evan Silberman wrote: > Hi ports, > > Here's a port of Nickel (https://nickel-lang.org/), a programmable > configuration language that allows both strong-typing and more dynamic > contract-driven specification of configurations. > > There doesn't seem to be a uniform approach to building ports of > applications that happen to be distributed as Rust crates; I'm just > using the cargo index as SITES here. That approach seema reasonable to me. Two things I noticed: - see line 1 of crates.inc - LIB_DEPENDS is not valid unless there's a WANTLIB coming from that port - there should be an error message due to this when running "make package", it's explained in bsd.port.mk(5) This is for after 7.4 I think.
