by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Bryan Richter
@chreekat
Hi all, hello from NixCon 2019. :) Is anyone else here?
Plus, I would like to work on hnix during the Sunday hackday. @jwiegley , @mightybyte any suggestions for work items?
Bryan Richter
@chreekat
@domenkozar and @shlevy as well
Bryan Richter
@chreekat
I've been told this project is basically archived now 😅
Brian McKenna
@puffnfresh
:(
nooooooo
Ryan Trinkle
@ryantrinkle
@chreekat Who told you that?
Bryan Richter
@chreekat
@ryantrinkle archived was a strong word. Rather I just heard that some core contributors have run out of energy for the project.
I'm still interested in it myself, although I don't have any time to spare for it. :( I was hoping to use NixCon as a reason to get familiar with it, but didn't end up connecting with anyone. @domenkozar was around but was making progress on Hercules instead
Domen Kožar
@domenkozar
@chreekat should have pinged me, would love to help :)
Ryan Trinkle
@ryantrinkle
@chreekat I think a lot of us are in that same situation - interested but don't have time to spare. Obsidian has been growing (again! we'll be up to ~44 after this round of hiring), which will eventually help hnix and other community projects, but for now takes almost all of my time. I know @jwiegley has also been very busy at his job - also because of good things happening, afaict! In any case, I've been really happy about the amount of use this codebase has gotten even though it doesn't completely evaluate nixpkgs yet.
Domen Kožar
@domenkozar
I think more cooperation would help. Talk about the goals and joining up and focus on those closer to completion.
@chreekat can you share more about your goals?
Bryan Richter
@chreekat
@domenkozar , @ryantrinkle that's all good to hear! I'm also quite busy for good reasons, and was thinking NixCon would be a good opportunity to just dip my toes into the project. So I don't have any definite goals right now. However, we will be generating more and more nix expressions from Haskell apps soon, which makes hnix interesting
(I think?)
I assume hnix, like GHC, provides both a utility for evaluating nix expressions, as well as libraries for manipulating them
In that regard, has anyone looked at Trees That Grow? I tinkered with its usage in GHC, and I assume it would be useful to hnix as well. But I've strayed into the realm of idle gossip now, because that's a refactoring that I bet none of us has time for right now :)
matrixbot
@matrixbot
vaibhavsagar I personally want us to get a comment-preserving parser before embarking on a TTG refactoring
Bryan Richter
@chreekat
Does gitter not send mobile notifications? Or is it just me?
tomberek
@tomberek
@Anton-Latukha i remember seeing a POSIX nix installer earlier. What's needed for a merge?
John Wiegley
@jwiegley
Hi @Anton-Latukha !
Anton Latukha
@Anton-Latukha

@jwiegley
I understood you.

You are right, things like this must be transcended.

Thank you for properly moderating and giving a chance for self-correction.

John Wiegley
@jwiegley
Did I really communicate all of that by saying, "Hi"? Wow!
Anton Latukha
@Anton-Latukha

@tomberek
PR was ready for 2 years, and I've done a lot of work trying to merge it.

With the current state in the upstream installer, it can be safely assumed that POSIX installer would not be merged. Merging it would mean to allow me greatly simplify and refactor all installers there into one installer codebase. This is unreal to expect that this would be allowed and happen.

Compl Yue
@complyue
just found here, help needed on this strange situation NixOS/nixpkgs#73443
can this bcoz pre-built GHCs from nixpkgs were built in env purer than my local one? I've tried on both macOS mojave and Ubuntu 18.04, same result.
Anton Latukha
@Anton-Latukha

@complyue

Sorry for long response.

Nix already has idealized build setup implemented, if you have:

nix.useSandbox = true;   # under NixOS 'true' is default

It is the main advertised feature and everything NixPkgs builds and pains upon.

To check:

nix-shell
echo $IN_NIX_SHELL
# must be 'pure'

HNix internally uses Nix for many processes. Since I did not read the code that does build - I am sure HNix reuses build environment abstraction from Nix, AKA nix-shell.

AFAIK, Nix build environment on macOS did not had "pure" mode, only "impure".
Ubuntu AFAIK should be able to do/enabled "pure" Nix build mode.

I would've recommended the use of a container, or entire NixOS host/vm - those allow "pure" build.

GHC use to use two versions of GHC to build new one, and anyway at least should use old version of itself to build itself, and also had a requirement to be able to do that without package management, which lead to internal conflicts/collisions, for example of libraries, during build. Maybe you had something related to that. I do not see how in current state Nix can solve that. Official GHC docs&Guides you probably seen.

So, in short, HNix can not help you in any way.

Anyway interested what problem was about and what the continuation was.

Richard Marko
@sorki
ping!
Compl Yue
@complyue
@Anton-Latukha Thanks for the response, I ended up solving it by not renaming GHC 's name in the nix expr, cdepillabout@github who helped me alot neither thought it should be a problem but anyway it worked out that way.
matrixbot
@matrixbot
Ericson2314 https://github.com/haskell-nix/hnix/issues/328#issuecomment-605466836 what do you all think about splitting the packages and merging the repos?
Ericson2314 I like the pairing of the two--monorepo offsets difficulties of smaller packages.
Anton Latukha
@Anton-Latukha

My PR is dependent of any big Haskell code reshuffles/changes.

I see that this is about Nix packaging. It would be good to atomize the builds of course.

Anton Latukha
@Anton-Latukha
/Nix&Cabal packaging/.
Anton Latukha
@Anton-Latukha

+====

Lets continue our out of Report and PR discussions here, this chat is for this, any current stuff.

I've fixed something in my understanding and Travis CI.
Anton Latukha
@Anton-Latukha

From now on Travis CI would indeed mandatory do a daily build of the master branch.

Since the Hydra channel builds update several times a day, and Nixpkgs-unstable releases frequently.

And quite freuently PRs can not pass the CI since they need a >50m rebuild of the stack.

========

Now CI prepares a fresh cache for PRs every day, so PR builds would pass in stable times ~9-10 minutes and they more stably would pass in 50 min Travis free tier mark if rebuilds happen.

========

Of course, as always, it would be great to receive the rights to migrate the project to more flexible CI/s, for example, GitHub Actions seem to have much faster machines, much cleaner more cared for Nix profile setup and faster node startup times. These in their sum going to result in the crunch of builds in 3/4 of the current time, wich would be great for testing of the development processes.

And, moreover, to the current practice of heating-up the Nix cache, GitHub Actions also has the virtually unlimited time of the builds, which is in line with Nix stack paradigm. That would result into a much more stable CI.

Anton Latukha
@Anton-Latukha

+====

Not so long ago I received/created and overloaded consciousness with multitasking/multithinking, and also noticed that it was not pleasant and also dampened the abilities, concentration, prioritization, and getting things done overall.

So, I rested for a couple of days, and need a couple of day more to switchback/transform into the proper mode. I definitely recommend to stick to some prioritization system, but also I myself already made shoes but do not walk in them, and also need a better integrate between Org-mode, GTD, myself and the browser, or better with GitHub 8)

Richard Marko
@sorki
Hehe, I've discovered freemind recently and it helped quite a lot to organize my thoughts regarding multiple interleaved projects
btw found a weird bug of shell.nix - I can't pass compiler to it correctly via nix-shell --argstr compiler ghc8101. Only works if I adjust it and change {} @ attrs: (import ./. attrs).env to { compiler ? "ghc8101" } @ attrs: (import ./. attrs).env. Works fine with default.nix
Anton Latukha
@Anton-Latukha

+====

I want to start a chat meeting. And would right-ahead address the main topic of this chat, let us recollect how we behave and sound, especially myself:

https://www.youtube.com/watch?v=LFrdqQZ8FFc

Remembering this makes easier to find a balance, be more effective in thoughts, actions, dialogs, and life. This gives a proper approach and prioritization.

Richard Marko
@sorki
Maybe we could schedule these chat meetings, like every Tuesday at 6PM UTC so we have a chance to sync.
Simon Jakobi
@sjakobi
Thanks for that youtube link, @Anton-Latukha! ;)
Simon Jakobi
@sjakobi
In general I prefer asynchronous written communication, because it gives me more flexibility and enough time to collect my thoughts. I'd be fine with syncing up once in a while though. Also, I'm not a big fan of text chat. I always find that a bit stressful. If we want to have a meeting, how about a video call? Maybe once or twice every month?
Anton Latukha
@Anton-Latukha
Well, that sketch is a classic.
Anton Latukha
@Anton-Latukha

+====

We with Sorki had quite a conversation about IRC as an official channel.

We never found a middle ground in the conversation.

+====

But for me the middle-ground is simple.

The shortcomings of IRC are widely known. IRC is by design not suitable for technical support.

Gitter is the best platform to index, hold, and exchange technical support.
Gitter is transparent all around, it has the best message format (supporting multiline, Markdown, etc), transparent with GitHub and with web search engines (logs questions and responses included and so slash the volume of support exponentially) (transparent logging in a small community can be seen as an own "Stack overflow" for free), and since we are on GitHub, Gitter is drop-in and intuitive for the new community members.

The persistent chat & logging + the bridge allows future migration from it to any other solution. We can just stop using Gitter and switch to another platform, and all most important in chat (information knowledge base) is preserved.

The HNix theme has a small scope and message volume. But, as always, we have many platforms, and so as a community is scattered over them, and as a small community interested to be strong and growing - we are interested to gather every member of our small community into the global chat room. So I am in favor of integrating the Gitter, IRC, Telegram, Discord, and Matrix with Matrix bridges. Matrix is for the nearest years has the best set of bridges and the ability of beings the central hub between protocols.

And due to the low scope of the theme (HNix), and so minimal volume of messages - this would be a minor inconvenience for some for the global major gain.

That would also provide the IM choise for all members, so they can indeed be online in the chat room.
Anton Latukha
@Anton-Latukha

+====

Regarding scheduled meetings:

I do not think currently scheduled "meetings" are needed. At least in nearest months. Especially in the current state of our HNix Opens Source community.

People in Open Source also can be in quite contrary time zones and have different lifestyles, it is hard to make a good scheduled meeting. If someone wants more scheduled meetings, an office job with hard management, SCRUM, Agile is a good place to start. I held enough of those. They can be good in intencive situations, but not currently, there is not much to discuss live currently, scheduling meetings would only psychologically devert people, especially in the volunteer project.
I always felt and think that with smart Haskell people - soft management and constant soft priorities setting is the best efficient approach.

+====

Softly proposing the soft sync:

I am for just, like. We can agree to, when someone decides to share some information or status for others, that we would try to post it on some weekday, and so on the next day of the week, people can read and sync-up with each other.

  1. Since it is Open Source community. Many contributors contribute and would contribute in a free time manner (the freest time - weekends);
  2. Haskell is known to be THE weekend hero of the IT industry;
  3. People are more calm and casual on the weekend.

I think that the Friday evening, Saturday until eveening - is a good day to post our info into the chat, so over the weekend regardless of our location on Earth, on Saturday and Sunday, we would have enough time to sync-up with one another, and we allways can continue to sync-up through the week further.

Anton Latukha
@Anton-Latukha

+====

Also, the GitHub profile is a good passive news source.

+====

My status:

I had a casual pleasant week. Become much more self-aware and gathered.
I am currently in the Nixpkgs-with-Haskell.

Learned GitHub CI, so reporting on it.

Well, docs are, just as Travis CI docs (or Saltstack or any closed docs), are not great.

I would also say GitHub CI even with its preview not using YAML and introducint it later, CI configuration mixed-up the use of the YAML typing system, it is strange that API is sets, some custom data also set and other data is a list. So result is CI API and custom data collections mixed into one type.

Also GitHub CI does not follow the basic YAML spec requirements. So after seeing that I do not know how they would parse more (satire) complex YAML.

Some strangeness in the design of the scoping, addressing, matrices.

But the configurability already blows Travis CI out of the water:

Every build is a proper separate check, so it is known what zone falls so there is even no need to go into CI to look the state of the PR check.

Also, a separate badge can be made for every particular workflow, which is a poor-mans-version monitoring for the current state of the project.

Overall free tier CI is great, and great for our cases.

I wished Install-Nix-Action was a ready container, in that way the CDN would not block the node due to the simultaneous number of installer downloads, since current limits are low - it is easy to overflow the limit.

+====

I think that it is hardly a CI lock-in.

  1. We already on GitHub
  2. I raised the discussion on migration, and nobody stood-up to migrate to GitLab.
  3. All neighboring communities we intertwine with are on GitHub.
  4. But the main thing, porting/extending a classical CI is not a big deal for me. Reading, and porting some YAML. While a new CI extends in features and quality over previous one - the migrations are easy, for me, CIs and migration between them is one of the easiest technology monomorphisms, if the codomain is bigger.

+====

The Nix CIs (Hydra, or Hercules...) are completely the other migrations, of course.

Even if we grow to use Nix-paradigm CI, no one prevents us from using particular features from many CIs.

+====

BTW, still need to pick a name for "haskell-with-nixpkgs" - open to ideas.