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
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.

Anton Latukha
@Anton-Latukha

+====

2020-07-11

+====

Hey, good day everybody.

This week I worked on haskell-with-nixpkgs.

And the project setup became mature enough to start being drop-in and start sharing it. So to test and improve upon it - it needs further application from one side. From the other side - our projects need the expansion of CI testing to be staples of quality. Third - hnix-store does not have CI at all, so I brought all our the results into it in this PR: haskell-nix/hnix-store#69. Fourth - the hnix-store is a monorepo of two projects with non-traditional Nix setup, so that is a good task to do to make haskell-with-nixpkgs most versatile.

As you see - in PR I even transacted all authors works and all proper commit history from HNix into haskell-with-nixpkgs, and now to Hnix-store, so everyone contributed for their work on this setup.

Since the proper Git practice is to treat PRs abstractly - https://github.com/Anton-Latukha/git-bisect-master-pr - I would continue to keep Git commit history atomic and preserving the real evolution histories, so things stay original, attributed to authors and moreover can be debugged properly and precisely.

+====

The CI results for hnix-store you can see at: https://github.com/Anton-Latukha/hnix-store/pull/1/checks

For project that was kept without CI beforehand - the HNix-store is currently kept in great condition - a tribute to maintainers.

Anton Latukha
@Anton-Latukha

+====

I merge valuable progress haskell-with-nixpkgs into hnix-store direcly - because hnix-store already has its custom Nix infrastructure around, so I see that the best way to bring abilities is to merge them into the project.

haskell-with-nixpkgs forms to have 2 modes:

  1. For projects that do not have Haskell-Nix integration - a drop-in working submodule would be provided, which would go in a subdirectory and all Nix related stuff would be kept there to keep the classical Haskeller programmers projects clean and at the same time show them the possibilities of the Nixpkgs.
  2. For projects that already have an infrastructure - depending on their setup or submodule, or custom merging of the project code results into their codebase.

Soon, after we get done with hnix-store merge, I would bring the progress of CI back into HNix, so we would replace the Travis CI with the much more versatile and flexible for us variant.

The HNix CI transition would require the action of creating of the Chachix HNix secret for use in GitHub CI.

Anton Latukha
@Anton-Latukha
/Cachix
Anton Latukha
@Anton-Latukha

I want to merge CIs so we can casually track the state and maintain the projects whatever happens in the future. I want to finish laying base cornerstones our CIs and then finish forming haskell-with-nixpkgs for the community and publish it.

I ran my life and honest learning on my own resources saved 2.5 years ago, I actually ran out of them already last year. I decided that I have proper character and education now, so I started to look for paid work yesterday, so my activity may/should drop in the future. That is why I want to finish with base of the CIs, so then CIs would help me to prioritize - when I have time I would be able to laser focus it on the main priority task I see most effective for the future of the project - the HNix/HNix-store maintenance, progress on community onboarding, evaluation of the Nipkgs store graph, which would result in the rapid growths of the commuity, and so then further maintenance of the progress...

Anton Latukha
@Anton-Latukha

+====

0.9.1 is out to Hackage.

Sorki made a major contribution, now REPL supports multiline expressions.

Anton Latukha
@Anton-Latukha

+====

Topic: Haskell & Nix integration:

We can add the ability for HNix to load HIE:

Infinicil recently stabilized the new generation of all-hies.

He suggested the example solution in:
Infinisil/all-hies#71

Had complette Emacs Nix Haskell IDE Engine integration mid 2019-2020, but then all-hies broke because of stack2nix closing. Now all-hies is back and switched from globall setup to per-project nix-shell setup.

I am interested in who uses Nix & HIE, and thoughts on such integration, and maybe someone would finish it before me.

Or maybe some have working setup to share.

Joel McCracken
@JoelMcCracken_gitlab
is hnix at the point where its usable?
Joel McCracken
@JoelMcCracken_gitlab
I'm curious if I would be able to use it to for example script my home manager config