On Wed, 31 May 2017, 17:23 Benno Fünfstück,
wrote:
> Profpatsch schrieb am Mi., 31. Mai 2017 um 16:01 Uhr:
>
>> On 17-05-31 08:25am, Benno Fünfstück wrote:
>> > A package set
>> > is a consistent set of packages of a given language.
>>
>> exactly that is not possible with e.g. npm or golang pack
Profpatsch schrieb am Mi., 31. Mai 2017 um 16:01 Uhr:
> On 17-05-31 08:25am, Benno Fünfstück wrote:
> > A package set
> > is a consistent set of packages of a given language.
>
> exactly that is not possible with e.g. npm or golang packages.
>
Yes, those should be dealth with differently. Is sha
On 17-05-31 08:25am, Benno Fünfstück wrote:
> A package set
> is a consistent set of packages of a given language.
exactly that is not possible with e.g. npm or golang packages.
--
Proudly written in Mutt with Vim on NixOS.
Q: Why is this email five sentences or less?
A: http://five.sentenc.es
M
I think that as a first step, we have to separate two use cases for nixpkgs:
* creating development environments to use with nix-shell etc
* installing applications
Package sets are key here. An application is built against a specific
package set, and a development environment is based on a packa
On 17-05-30 08:02am, Wout Mertens wrote:
> This actually ties into my question about nodePackages. It seems to me that
> for these large packaging systems, we should have separate repos that
> update from their source, and you can then include them into your nixpkgs
> configuration.
nodePackages i
Freddy Rietdijk writes:
> Hi,
>
> At several places in Nixpkgs we use auto-generated data, mostly for the
> larger package sets like Haskell. Sometimes we also use auto-generated sets
> for applications that may need different versions than are offered in the
> main package sets. In the past mont
> Current approach seems to be doing the job except notifying people when
dependency is updated.
What do you base that on? With the generated data sets for applications we
have another issue which I didn't mention, and that is the sometimes overly
conservative pinning of versions by the applicatio
Current approach seems to be doing the job except notifying people when
dependency is updated. Previously we had monitor to do some similar stuff,
and I think vulnix can check that without much effort so I wouldn't worry
about having duplicated packages for apps.
I think focusing on improving CI pr
Let met try to sum up what I remember:
- There 3+ solutions to update "sources" documented on the wiki
somewhere - ideas from comparing versions with other distributions up
to adding scrapers getting latest version from web sites if I recall
correctly
- Putting automatically generated code
Freddy Rietdijk writes:
> Hi,
>
> At several places in Nixpkgs we use auto-generated data, mostly for the
> larger package sets like Haskell. Sometimes we also use auto-generated sets
> for applications that may need different versions than are offered in the
> main package sets. In the past mont
This actually ties into my question about nodePackages. It seems to me that
for these large packaging systems, we should have separate repos that
update from their source, and you can then include them into your nixpkgs
configuration.
Only packages that are useful by themselves should get a deriva
Hi,
At several places in Nixpkgs we use auto-generated data, mostly for the
larger package sets like Haskell. Sometimes we also use auto-generated sets
for applications that may need different versions than are offered in the
main package sets. In the past months several issues/PR's have been open
12 matches
Mail list logo
