Re: plan.json documentation

[Oleg Grenrus]

A short answer: Look how cabal-docspec is implemented. It does do what
you want (i.e. finds all source files) to do its job too.

A slightly longer version:
- cabal-plan library parses plan.json, its types tell you what is there [1]
- plan doesn't include location of .cabal files directly, but it has
PkgLoc. From there you can find .cabal files
- in cabal-docspec (and cabal-hie) for that matter, I simplify GPD parts
using flags information in plan.json to figure out exactly which modules
are in play
    - this part is too complicated, can probably be done simpler with
finalizePD [2]
- cabal-docspec uses utilities in cabal-extras repository to figure out
GHC information for the previous step.

It's not simple, you need to combine parts, but all pieces are there.

- Oleg


[1]:
https://hackage.haskell.org/package/cabal-plan-0.7.2.0/docs/Cabal-Plan.html
[2]:
https://hackage.haskell.org/package/Cabal-3.4.0.0/docs/Distribution-PackageDescription-Configuration.html#v:finalizePD

On 19.3.2021 22.20, Nicolas Frisby wrote:
> Hi all. Without show-build-info yet and without a cabal-install
> library, a hobby project relies on parsing plan.json to access eg the
> list of .cabal files and their flags as configured during the most
> recent cabal-install invocation.
>
> I haven't found much documentation about plan.json. I'm particularly
> curious what are its current semantics and intended use, and if these
> are intended to remain stable going forward.
>
> Some example specific questions:
>
>   * Would show-build-info supplant plan.json? If so, would there be a
> deprecation delay?
>
>   * The docs say "A JSON serialization of the computed install plan
> intended for integrating cabal with external tooling." It seems likely
> that answering my questions will involve explaining what an "install
> plan" is. (I'm unfortunately unfamiliar with Cabal internals, and
> ReadTheDocs search doesn't seem to support phrases as queries.)
>
>   * What determines which packages have entries in the plan.json file
> after a particular cabal-install invocation? Will it always include
> all local .cabal files? (爛)
>
>   * Is there enough information in the plan.json file in order to map
> an entry there for source repository package to the corresponding path
> under the builddir's `src` directory? There seems to be some sort of
> hash involved in that path and I haven't figured what its inputs are
> and whether the plan.json file includes them all.
>
> Thank you for your time. -Nick
>
> PS - My hobby project driving this question is based on wanting to
> parse all local source files without having to typecheck/build any of
> them (ideally nor their non-local dependencies). I need each source
> file path and corresponding language extensions etc in order to invoke
> the parser. (hie-bios doesn't suffice because its solution to this
> problem involves building dependencies, possibly including local
> packages.)
>
> If you see a more direct path that doesn't involve plan.json, please
> say so. Thanks again!
>
> ___
> cabal-devel mailing list
> cabal-devel@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: [RFC] Qualified module renamings

[Oleg Grenrus]

How this will work with packages adding modules.

For concrete example:

- parsec-backpack-0.1 provides two modules Parsec.Prim and
Parsec.Combinators
- in my library, I instantiate Parsec.* to Parsec.Text.*, and
Parsec.String.*, I get four modules. That is nice.
- parsec-backpack-0.1.1 is released adding Parsec.Error. I get six
modules. That is still fine as they are not exported.

However, if the same example is done for re-exported modules, my library
public interface would change depending on (minor) version of a
dependency. This is no go in Hackage context.

As far as I can see it, reexported-modules and wildcards are no go.

Something like

    reexported-modules: [ [ Parsec.Text.m, Parsec.String.m] | m <- [
Prim, Combinators ] ]

or

    reexported-modules: for m in [Prim, Combinators]: Parsec.Text.m,
Parsec.String.m

or some variation of that idea which fits cabal/module syntax would be
both explicit and still more convenient.

I also think it will be even easier to implement, as you all information
is there, you don't need to know any context to expand it.

- Oleg

On 25.2.2021 23.01, Edward Z Yang wrote:
>
> > It took me about five minutes to arrive at the guess that this is
> about the syntax in Cabal files for using backpack - is that right?
>
>
> Oops yes, sorry for omitting this context.
>
>
> > What is the intent of what got implemented, anyway? Are there
> example use cases?
>
>
> I'm not exactly sure what you mean by intent. But a common pattern in
> Backpack is to instantiate a library multiple time with different
> requirements, and if you want them all in scope you have to rename
> them. Right now, this has to be done one-by-one for each provided
> module, which can be a bit annoying. For example, let say you
> parametrized parsec by string type, and you wanted a bytestring
> version and a text version, it would be convenient to be able to
> unconditionally rename every Text.Parsec.* module to
> Text.Parsec.*.ByteString (for example)
>
>
> Edward Kmett described a concrete motivating use case
> at https://github.com/haskell/cabal/issues/7290#issuecomment-783540208​
> although his use case is a little difficult to understand.
>
>
> Edward
>
>
> 
> *From:* Bryan Richter 
> *Sent:* Thursday, February 25, 2021 10:06 AM
> *To:* Edward Z Yang
> *Cc:* cabal-devel@haskell.org; ekm...@gmail.com
> *Subject:* Re: [RFC] Qualified module renamings
>  
> It took me about five minutes to arrive at the guess that this is
> about the syntax in Cabal files for using backpack - is that right?
>
> What is the intent of what got implemented, anyway? Are there example
> use cases?
>
> Den tors 25 feb. 2021 18:14Edward Z Yang  > skrev:
>
> Today, using the 'mixins' field you can rename modules that come
> from other packages by manually expressing a renaming one-by-one.
> In some Backpack use cases, you may have a lot of modules that you
> would like to mechanically rename into some subnamespace; today,
> you have manually list each renaming one by one.
>
>
> https://github.com/haskell/cabal/pull/7303 contains an
> implementation of one possible way to extend mixin syntax to
> support qualified renaming; the implementation is very simple. The
> syntax here is based off of Richard Eisenberg's local modules
> proposal (https://github.com/ghc-proposals/ghc-proposals/pull/283)
> which supports the qualified keyword before module exports/imports
> which has the same effect (bring the module into scope under a
> sub-module namespace). However, the PR isn't really meant to be an
> end all to the discussion: it's just to show that it's pretty
> simple to implement this functionality.
>
>
> There are two primary axes which I am looking for feedback:
>
>
> * Expressivity. The current PoC implementation only permits
> unconditionally prefix-ing all modules that would have been
> brought into scope by the mixin; e.g., transforming module A to
> Prefix.A. Edward Kmett has expressed that in some cases, he would
> like it if you could implement the import as a suffix. One could
> also imagine allowing arbitrary string transformations. Opinions
> on where to draw the line for expressivity are solicited.
>
>
> * Syntax. The current syntax is "pkgname qualified Prefix" as it
> is symmetric with "pkgname hiding (A, B)" and it was simple to
> implement. But I am not particularly attached to this syntax, and
> am open to other suggestions. If we permit suffixing, a wildcard
> based syntax like "pkgname (* as *.Suffix)" may be preferable
> (though modestly more complex to specify and implement; for
> example, is the glob recursive over dots?). Edward Kmett has
> offered some other possibilities
> at https://github.com/haskell/cabal/issues/7290#issue-812744575​
>
>
> Thanks Oleg for reminding me to send this 

Re: RFC: A plan to gradual removal of v1- commands

[Oleg Grenrus]

Dear cabal co-developers [3]

A month ago I asked about my plan to remove v1- commands.
There weren't any replies on the mailing list,
I don't remember whether there there where any response on Twitter,
The few comments on Reddit [1] were
- don't remove until v2 functionality complete and bugless
- remove v1-commands immediately, people who need them may keep using old
  cabal-install

I interpret that my conservative "remove eventually, but not immediately"
plan got approval of silent majority. No hot debate = good.

Therefore I'll proceed with the proposed plan. I already made a small
patch to
remove v1-upload [2], and will create patches and issues for the rest.

Cheers, Oleg

[1]
https://www.reddit.com/r/haskell/comments/j0ruyx/rfc_a_plan_to_gradual_removal_of_v1_commands/
[2] https://github.com/haskell/cabal/pull/7151
[3] What is codeveloper, category theoretically?


On 27.9.2020 17.18, Oleg Grenrus wrote:
> Dear development aware cabal users
>
> I request you to comment on a plan to gradually remove `v1-` commands.
>
> Some users have commented about the notice in `v1-` commands' `--help`:
>
>   It is a legacy feature and will be removed in a future release of
>   cabal-install. Please file a bug if you cannot replicate a working v1- use
>   case with the nix-style commands.
>
> This note is vague, and indeed we don't have any concrete plan *when*
> something will be removed.
>
> Lets have one.
>
> At the moment, in upcoming `cabal-install-3.4.0.0` we have following
> commands:
>
>   v1-build  Compile all/specific components.
>   v1-configure  Prepare to build the package.
>   v1-repl   Open an interpreter session for the given component.
>   v1-run    Builds and runs an executable.
>   v1-test   Run all/specific tests in the test suite.
>   v1-bench  Run all/specific benchmarks.
>   v1-freeze Freeze dependencies.
>   v1-haddock    Generate Haddock HTML documentation.
>   v1-exec   Give a command access to the sandbox package repository.
>   v1-update Updates list of known packages.
>   v1-install    Install packages.
>   v1-clean  Clean up after a build.
>   v1-doctest    Run doctest tests.
>   v1-copy   Copy the files of all/specific components to install
> locations.
>   v1-register   Register this package with the compiler.
>   v1-reconfigure    Reconfigure the package if necessary.
>
> I propose the following plan:
>
> In 3.4.0.0 (to be officially released in a week from GHC-9.0.1 release,
> i.e. soon)
> we have already removed `v1-sdist`, as `v2-sdist` have completely
> subsumed the
> functionality, yet the interface is slightly different.
>
> In 3.6.0.0 (to be release around GHC-9.2) we will remove
>
>    - v1-update:  the v2-update should already completely subsume the
> functionality
>  (but this have to be checked)
>    - v1-doctest: is a commeand which never worked properly
>    - v1-exec:    its description mentions sandbox package repository,
>  as sandbox are already removed, v1-exec has no use
>
> In 3.8.0.0 we will remove what I'd call "interactive" development
> commands:
>
>    - v1-freeze
>    - v1-bench
>    - v1-reconfigure
>    - v1-repl
>    - v1-run
>    - v1-clean
>
> These are commands which I don't expect to be heavily used in scripts.
>
> That would leave us with what I consider essential commands.
> I think these are sufficient if `v1-` commands are used in some
> bigger build process. (Though, I'd suggest to use raw `./Setup`)
> This can be removed in 3.10 (or more conservatively in 3.12).
>
>    - v1-build
>    - v1-configure
>    - v1-haddock
>    - v1-test
>    - v1-install
>    - v1-copy
>    - v1-register
>
> These commands will be removed in 3.12 (skipping the 3.10).
>
> In summary:
>
>   v1-sdist  now  3.4
>   v1-build  two years    3.12
>   v1-configure  two years    3.12
>   v1-repl   one year 3.8
>   v1-run    one year 3.8
>   v1-test   two years    3.12
>   v1-bench  one year 3.8
>   v1-freeze one year 3.8
>   v1-haddock    two years    3.12
>   v1-exec   6 months 3.6
>   v1-update 6 months 3.6
>   v1-install    two years    3.12
>   v1-clean  one year 3.8
>   v1-doctest    6 months 3.6
>   v1-copy   two years    3.12
>   v1-register   two years    3.12
>   v1-reconfigure    one year 3.8
>
> I should mention that we don't test any of `v1-` commands anymore.
> The code is there, and if it works it is good, but if it doesn't,
> we wont actively pursue fixin

cabal-install-3.4.0.0-rc4 and Cabal-3.4.0.0-rc4 are now available

[Oleg Grenrus]

The Cabal developers are happy to announce the fourth (and hopefully final)
release candidate for cabal-install-3.4.0.0

The corresponding tags are `cabal-install-3.4.0.0-rc4` and
`Cabal-3.4.0.0-rc4`

    https://github.com/haskell/cabal/releases/tag/cabal-install-3.4.0.0-rc4
    https://github.com/haskell/cabal/releases/tag/Cabal-3.4.0.0-rc4

and there is a handful of binaries available at

    https://oleg.fi/cabal-install-3.4.0.0-rc4/

Ubuntu-16.04 bindist should work on most recent Linux distributions,
(requires at least kernel 3.15, compiled against glibc-2.23).
Similarly darwin-sierra bindist should work on newer macOSes as well.

The binary distributions are built from the source distributions
of Cabal and cabal-install available at the same directory.
Additionally I have uploaded candidates to Hackage:

    https://hackage.haskell.org/package/Cabal-3.4.0.0/candidate
    https://hackage.haskell.org/package/cabal-install-3.4.0.0/candidate

---

NOTE: If you are testing the recently announced GHC-9.0.1-alpha1 [1],
it is highly recommended that you use cabal-install-3.4.0.0.

[1]: https://mail.haskell.org/pipermail/ghc-devs/2020-September/019286.html

---

Please comment on a plan for gradual removal of v1-commands.
https://mail.haskell.org/pipermail/cabal-devel/2020-September/010488.html

There have been few replies on reddit [2] but no replies on the mailing
list.

[2]:
https://www.reddit.com/r/haskell/comments/j0ruyx/rfc_a_plan_to_gradual_removal_of_v1_commands/

---

Since the third release candidate (rc3) following issues were resolved:

- Pass -optcxx for GHC >= 8.10
  https://github.com/haskell/cabal/issues/6421
  https://github.com/haskell/cabal/pull/7072
- Require custom-setup for cabal-version: 1.24 and later
  https://github.com/haskell/cabal/issues/7091
- Allow Win32-2.10.0.0
  https://github.com/haskell/cabal/pull/7085
- Remove v2-build beta note from --help
  https://github.com/haskell/cabal/issues/7090
- Fix command notes being replaced by descriptions
  https://github.com/haskell/cabal/pull/7089
- documentation: Nix style local builds have become the default
  https://github.com/haskell/cabal/pull/7097
- Provide slightly more information when there are multiple occurences
of same package
  https://github.com/haskell/cabal/pull/7078

Since the second release candidate (rc2) following issues were resolved:

- Regression in cabal repl handling of `-z` flag
  https://github.com/haskell/cabal/issues/7039
- Allow Win32-2.9.0.0
  https://github.com/haskell/cabal/issues/7040
- v2-update updates file+noindex repositories cach
  https://github.com/haskell/cabal/issues/7061
- Fix cabal sdist issues for packages with data-files
  https://github.com/haskell/cabal/issues/7028

Since the first release candidate (rc1) following issues were resolved:

- Bump process version required for job support to 1.6.9
  https://github.com/haskell/cabal/issues/6986
- GHC-8.12 is GHC-9.0
  https://github.com/haskell/cabal/issues/7019
- cabal-install-head v2-install fails to process source-repository-package
  https://github.com/haskell/cabal/issues/7007

cabal-install-3.4 release highlights are:

- Support for upcoming GHC-9.0
- Removal of sandboxes
- Improved public sublibrary support
- `active-repositories` configuration
- Various `cabal init` improvements
- Various `cabal sdist` improvements
- `source-repository-package` are not treated as local packages
- Added `list-bin` command

Complete release notes (drafts) are at:
https://github.com/haskell/cabal/tree/master/release-notes

Please do test this release and let us know if you encounter any issues:
https://github.com/haskell/cabal/issues

- Oleg

___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: RFC: A plan to gradual removal of v1- commands

[Oleg Grenrus]

I forgot to mention.

Discussion open until the end of October 2020, that is roughly five weeks.

- Oleg

On 27.9.2020 17.18, Oleg Grenrus wrote:
> Dear development aware cabal users
>
> I request you to comment on a plan to gradually remove `v1-` commands.
>
> Some users have commented about the notice in `v1-` commands' `--help`:
>
>   It is a legacy feature and will be removed in a future release of
>   cabal-install. Please file a bug if you cannot replicate a working v1- use
>   case with the nix-style commands.
>
> This note is vague, and indeed we don't have any concrete plan *when*
> something will be removed.
>
> Lets have one.
>
> At the moment, in upcoming `cabal-install-3.4.0.0` we have following
> commands:
>
>   v1-build  Compile all/specific components.
>   v1-configure  Prepare to build the package.
>   v1-repl   Open an interpreter session for the given component.
>   v1-run    Builds and runs an executable.
>   v1-test   Run all/specific tests in the test suite.
>   v1-bench  Run all/specific benchmarks.
>   v1-freeze Freeze dependencies.
>   v1-haddock    Generate Haddock HTML documentation.
>   v1-exec   Give a command access to the sandbox package repository.
>   v1-update Updates list of known packages.
>   v1-install    Install packages.
>   v1-clean  Clean up after a build.
>   v1-doctest    Run doctest tests.
>   v1-copy   Copy the files of all/specific components to install
> locations.
>   v1-register   Register this package with the compiler.
>   v1-reconfigure    Reconfigure the package if necessary.
>
> I propose the following plan:
>
> In 3.4.0.0 (to be officially released in a week from GHC-9.0.1 release,
> i.e. soon)
> we have already removed `v1-sdist`, as `v2-sdist` have completely
> subsumed the
> functionality, yet the interface is slightly different.
>
> In 3.6.0.0 (to be release around GHC-9.2) we will remove
>
>    - v1-update:  the v2-update should already completely subsume the
> functionality
>  (but this have to be checked)
>    - v1-doctest: is a commeand which never worked properly
>    - v1-exec:    its description mentions sandbox package repository,
>  as sandbox are already removed, v1-exec has no use
>
> In 3.8.0.0 we will remove what I'd call "interactive" development
> commands:
>
>    - v1-freeze
>    - v1-bench
>    - v1-reconfigure
>    - v1-repl
>    - v1-run
>    - v1-clean
>
> These are commands which I don't expect to be heavily used in scripts.
>
> That would leave us with what I consider essential commands.
> I think these are sufficient if `v1-` commands are used in some
> bigger build process. (Though, I'd suggest to use raw `./Setup`)
> This can be removed in 3.10 (or more conservatively in 3.12).
>
>    - v1-build
>    - v1-configure
>    - v1-haddock
>    - v1-test
>    - v1-install
>    - v1-copy
>    - v1-register
>
> These commands will be removed in 3.12 (skipping the 3.10).
>
> In summary:
>
>   v1-sdist  now  3.4
>   v1-build  two years    3.12
>   v1-configure  two years    3.12
>   v1-repl   one year 3.8
>   v1-run    one year 3.8
>   v1-test   two years    3.12
>   v1-bench  one year 3.8
>   v1-freeze one year 3.8
>   v1-haddock    two years    3.12
>   v1-exec   6 months 3.6
>   v1-update 6 months 3.6
>   v1-install    two years    3.12
>   v1-clean  one year 3.8
>   v1-doctest    6 months 3.6
>   v1-copy   two years    3.12
>   v1-register   two years    3.12
>   v1-reconfigure    one year 3.8
>
> I should mention that we don't test any of `v1-` commands anymore.
> The code is there, and if it works it is good, but if it doesn't,
> we wont actively pursue fixing it (rather concentrating on whatever
> issues are holding you from migration to v1-build).
>
> I would value comments whether the list for 3.6
> (v1-update, v1-doctest, v1-exec) is found controversial.
> Very rough estimate is that 3.6 will be released early 2021,
> in about a half a year from now.
>
> 3.8 would happen a year from now. (Fall 2021)
> 3.12 where the v1-build is gone would happen in two years from now.
> (Fall 2022)
>
> Disclaimers:
>
> I don't want to set the plan in stone.
> In other words, "All rights reserved",
> but we would avoid removing anything earlier than agreed.
> Yet, it's impossible to predict the future,
> and we might be forced to diverge from that plan.
>
> The version numbe

RFC: A plan to gradual removal of v1- commands

[Oleg Grenrus]

Dear development aware cabal users

I request you to comment on a plan to gradually remove `v1-` commands.

Some users have commented about the notice in `v1-` commands' `--help`:

  It is a legacy feature and will be removed in a future release of
  cabal-install. Please file a bug if you cannot replicate a working v1- use
  case with the nix-style commands.

This note is vague, and indeed we don't have any concrete plan *when*
something will be removed.

Lets have one.

At the moment, in upcoming `cabal-install-3.4.0.0` we have following
commands:

  v1-build  Compile all/specific components.
  v1-configure  Prepare to build the package.
  v1-repl   Open an interpreter session for the given component.
  v1-run    Builds and runs an executable.
  v1-test   Run all/specific tests in the test suite.
  v1-bench  Run all/specific benchmarks.
  v1-freeze Freeze dependencies.
  v1-haddock    Generate Haddock HTML documentation.
  v1-exec   Give a command access to the sandbox package repository.
  v1-update Updates list of known packages.
  v1-install    Install packages.
  v1-clean  Clean up after a build.
  v1-doctest    Run doctest tests.
  v1-copy   Copy the files of all/specific components to install
locations.
  v1-register   Register this package with the compiler.
  v1-reconfigure    Reconfigure the package if necessary.

I propose the following plan:

In 3.4.0.0 (to be officially released in a week from GHC-9.0.1 release,
i.e. soon)
we have already removed `v1-sdist`, as `v2-sdist` have completely
subsumed the
functionality, yet the interface is slightly different.

In 3.6.0.0 (to be release around GHC-9.2) we will remove

   - v1-update:  the v2-update should already completely subsume the
functionality
 (but this have to be checked)
   - v1-doctest: is a commeand which never worked properly
   - v1-exec:    its description mentions sandbox package repository,
 as sandbox are already removed, v1-exec has no use

In 3.8.0.0 we will remove what I'd call "interactive" development
commands:

   - v1-freeze
   - v1-bench
   - v1-reconfigure
   - v1-repl
   - v1-run
   - v1-clean

These are commands which I don't expect to be heavily used in scripts.

That would leave us with what I consider essential commands.
I think these are sufficient if `v1-` commands are used in some
bigger build process. (Though, I'd suggest to use raw `./Setup`)
This can be removed in 3.10 (or more conservatively in 3.12).

   - v1-build
   - v1-configure
   - v1-haddock
   - v1-test
   - v1-install
   - v1-copy
   - v1-register

These commands will be removed in 3.12 (skipping the 3.10).

In summary:

  v1-sdist  now  3.4
  v1-build  two years    3.12
  v1-configure  two years    3.12
  v1-repl   one year 3.8
  v1-run    one year 3.8
  v1-test   two years    3.12
  v1-bench  one year 3.8
  v1-freeze one year 3.8
  v1-haddock    two years    3.12
  v1-exec   6 months 3.6
  v1-update 6 months 3.6
  v1-install    two years    3.12
  v1-clean  one year 3.8
  v1-doctest    6 months 3.6
  v1-copy   two years    3.12
  v1-register   two years    3.12
  v1-reconfigure    one year 3.8

I should mention that we don't test any of `v1-` commands anymore.
The code is there, and if it works it is good, but if it doesn't,
we wont actively pursue fixing it (rather concentrating on whatever
issues are holding you from migration to v1-build).

I would value comments whether the list for 3.6
(v1-update, v1-doctest, v1-exec) is found controversial.
Very rough estimate is that 3.6 will be released early 2021,
in about a half a year from now.

3.8 would happen a year from now. (Fall 2021)
3.12 where the v1-build is gone would happen in two years from now.
(Fall 2022)

Disclaimers:

I don't want to set the plan in stone.
In other words, "All rights reserved",
but we would avoid removing anything earlier than agreed.
Yet, it's impossible to predict the future,
and we might be forced to diverge from that plan.

The version numbers are informative,
3.10 could be 4.0, or the release schedule could be accelarated or
slowed down.
We will stick to the time based definitions.

- Oleg

___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

cabal-install-3.4.0.0-rc3 and Cabal-3.4.0.0-rc3 are now available

[Oleg Grenrus]

The Cabal developers are happy to announce the third release candidate
for cabal-install-3.4.0.0

The corresponding tag are `cabal-install-3.4.0.0-rc3` and
`Cabal-3.4.0.0-rc3`

    https://github.com/haskell/cabal/releases/tag/cabal-install-3.4.0.0-rc3
    https://github.com/haskell/cabal/releases/tag/Cabal-3.4.0.0-rc3

and there is a handful of binaries available at

    https://oleg.fi/cabal-install-3.4.0.0-rc3/
 
Ubuntu-16.04 bindist should work on most recent Linux distributions,
(requires at least kernel 3.15, compiled against glibc-2.23).
Similarly darwin-sierra bindist should work on newer macOSes as well.

Since the second release candidate (rc2) following issues were resolved:

- Regression in cabal repl handling of `-z` flag
  https://github.com/haskell/cabal/issues/7039
- Allow Win32-2.9.0.0
  https://github.com/haskell/cabal/issues/7040
- v2-update updates file+noindex repositories cach
  https://github.com/haskell/cabal/issues/7061
- Fix cabal sdist issues for packages with data-files
  https://github.com/haskell/cabal/issues/7028

Since the first release candidate (rc1) following issues were resolved:

- Bump process version required for job support to 1.6.9
  https://github.com/haskell/cabal/issues/6986
- GHC-8.12 is GHC-9.0
  https://github.com/haskell/cabal/issues/7019
- cabal-install-head v2-install fails to process source-repository-package
  https://github.com/haskell/cabal/issues/7007

cabal-install-3.4 release highlights are:

- Support for upcoming GHC-9.0
- Removal of sandboxes
- Improved public sublibrary support
- `active-repositories` configuration
- Various `cabal init` improvements
- Various `cabal sdist` improvements
- `source-repository-package` are not treated as local packages
- Added `list-bin` command

Complete release notes (drafts) are at:
https://github.com/haskell/cabal/tree/master/release-notes

Please do test this release and let us know if you encounter any issues:
https://github.com/haskell/cabal/issues

- Oleg

___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

cabal-install-3.4.0.0-rc2 and Cabal-3.4.0.0-rc2 are now available

[Oleg Grenrus]

The Cabal developers are happy to announce the first release candidate
for cabal-install-3.4.0.0

The corresponding tag are `cabal-install-3.4.0.0-rc2` and
`Cabal-3.4.0.0-rc2`

    https://github.com/haskell/cabal/releases/tag/cabal-install-3.4.0.0-rc2
    https://github.com/haskell/cabal/releases/tag/Cabal-3.4.0.0-rc2

and there is a handful of binaries available at

    https://oleg.fi/cabal-install-3.4.0.0-rc2/
  
Ubuntu-16.04 bindist should work on most recent Linux distributions,
(requires at least kernel 3.15, compiled against glibc-2.23).
Similarly darwin-sierra bindist should work on newer macOSes as well.

Since the first release candidate (rc1) following issues were resolved:
- Bump process version required for job support to 1.6.9
https://github.com/haskell/cabal/issues/6986
- GHC-8.12 is GHC-9.0 https://github.com/haskell/cabal/issues/7019
- cabal-install-head v2-install fails to process
source-repository-package https://github.com/haskell/cabal/issues/7007

cabal-install-3.4 release highlights are:

- Support for upcoming GHC-9.0
- Removal of sandboxes
- Improved public sublibrary support
- `active-repositories` configuration
- Various `cabal init` improvements
- Various `cabal sdist` improvements
- `source-repository-package` are not treated as local packages
- Added `list-bin` command

Complete release notes (drafts) are at:
https://github.com/haskell/cabal/tree/master/release-notes

Please do test this release and let us know if you encounter any issues:
https://github.com/haskell/cabal/issues


- Oleg

P.S. Unfortunately I discovered yet another bug in cabal sdist behavior,
 which is triggered if you have packages with data-files.
 So there will be third release candidate.


___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

cabal-install-3.4-rc1 now available

[Oleg Grenrus]

The Cabal developers are happy to announce the first release candidate
for cabal-install-3.4.0.0

The corresponding tag is `cabal-install-3.4-rc1`,

    https://github.com/haskell/cabal/releases/tag/cabal-install-3.4.0.0-rc1

and there is a handful of binaries available at

    https://oleg.fi/cabal-install-3.4.0.0-rc1/

Ubuntu-16.04 bindist should work on most recent Linux distributions,
(requires at least kernel 3.15, compiled against glibc-2.23).
Similarly darwin-sierra bindist should work on newer macOSes as well.

cabal-install-3.4 release highlights are:

- Support for upcoming GHC-9.0
- Removal of sandboxes
- Improved public sublibrary support
- `active-repositories` configuration
- Various `cabal init` improvements
- Various `cabal sdist` improvements
- `source-repository-package` are not treated as local packages
- Added `list-bin` command

Complete release notes (drafts) are at:
https://github.com/haskell/cabal/tree/master/release-notes

Please do test this release and let us know if you encounter any issues:
https://github.com/haskell/cabal/issues

On 25.7.2020 13.07, Oleg Grenrus wrote:
> Dear all,
>
> Last week I tagged Cabal-3.4 release candidate. After fixing few
> immediately obvious issues with cabal-install, I have successfully used
> it for a week.
>
> This week I have been working on improving scripts for bootstrapping and
> release packaging, and as intermediate result there are
>
> - x86_64-darwin-sierra
> - x86_64-ubuntu-14.04
> - x86_64-alpine-3.11.6
> - amd64-freebsd-12.1-RELEASE
> - aarch64-ubuntu-18.04
>
> bootstrapped builds at
>
> https://oleg.fi/cabal-install-3.4.0.0-rc1-bootstrapped/
>
> The ubuntu-14.04 build works on later ubuntu, debian, and centos which I
> tried (in docker). Note, alpine build is not static, i.e. it dynamically
> links against musl.
>
> Please try these out, especially try to build cabal-install (from 3.4)
> branch, and use it, so we can fix most of regressions since 3.2.
> I'm specially interested whether the darwin/macos build works on newer
> macos versions.
>
> The release notes for Cabal-3.4 and cabal-install-3.4 are available at
> https://github.com/haskell/cabal/tree/master/release-notes
>
> - Oleg
>
>
> ___
> cabal-devel mailing list
> cabal-devel@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel



signature.asc
Description: OpenPGP digital signature
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Cabal-3.4 release candidate 1

[Oleg Grenrus]

Dear all,

Last week I tagged Cabal-3.4 release candidate. After fixing few
immediately obvious issues with cabal-install, I have successfully used
it for a week.

This week I have been working on improving scripts for bootstrapping and
release packaging, and as intermediate result there are

- x86_64-darwin-sierra
- x86_64-ubuntu-14.04
- x86_64-alpine-3.11.6
- amd64-freebsd-12.1-RELEASE
- aarch64-ubuntu-18.04

bootstrapped builds at

https://oleg.fi/cabal-install-3.4.0.0-rc1-bootstrapped/

The ubuntu-14.04 build works on later ubuntu, debian, and centos which I
tried (in docker). Note, alpine build is not static, i.e. it dynamically
links against musl.

Please try these out, especially try to build cabal-install (from 3.4)
branch, and use it, so we can fix most of regressions since 3.2.
I'm specially interested whether the darwin/macos build works on newer
macos versions.

The release notes for Cabal-3.4 and cabal-install-3.4 are available at
https://github.com/haskell/cabal/tree/master/release-notes

- Oleg


___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Release 3.4 planning

[Oleg Grenrus]

Dear cabal developers and users

As GHC-8.12 release plan was announced [1].
I suggest that we cut the 3.4 branch at the end of June,
i.e. after the first GHC-8.12 alpha release.

I opened an issue for discussion: [2]

https://github.com/haskell/cabal/issues/6757

---

I renamed previously existing 3.4 milestone to "Considered for 3.4". [3]
At the moment there are 64 open issues.

I will go though them ASAP.

- if there is an assignee ping them, whether they are working on the issue
  - if positive, we'll add it to 3.4 milestone
- assign few unassigned issues to myself, which I think I could complete
  - I already started work on the last mile/yard/foot of public 
multi-libraries.


At the end of May (in two weeks), I'll remove "Considered for 3.4"
issues.

The goal is that the issues in release milestones have someone working
on them (i.e. they are assigned to someone).

The reasoning for above is that we most likely won't resolve all of the 
60 issues,

and we have  "priority: low" and "priority: high" labels
to hint "how soon we should start working on them".

Please bring other issues (not in "Considered for 3.4") milestone in
issues #6757 [2], if you will work on them.
Especially if they are clear tasks, which don't require bikeshedding.

---

Also the special highlight: We removed sandboxes for cabal-install-3.4
https://github.com/haskell/cabal/issues/6445

Related to the issued of the `cabal install --lib` which is not exactly 
bug free.

That might prevent transition to v2-build for someone.

There is an issue about separating that functionality into a subcommand
for package environment management. The comment [4] sketches the design.
Please read though the issue and feel free to ask questions like "how I
would..." if you have any.  This way we can make good initial design.
(I'm spoiled by cabal-env design, but I haven't found an issue
which won't fit into its way of working).
Unfortunately I'd leave this feature out of 3.4 as we don't have clear and
agreed design.

- Oleg

[1]: https://mail.haskell.org/pipermail/ghc-devs/2020-May/018851.html
[2]: https://github.com/haskell/cabal/issues/6757
[3]: 
https://github.com/haskell/cabal/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Considered+for+3.4%22

[4]: https://github.com/haskell/cabal/issues/6481#issuecomment-620865817
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: Installation failed

[Oleg Grenrus]

y fallback)

Downloaded   ed25519-0.0.5.0

Downloading  zlib-0.6.2

Starting ed25519-0.0.5.0 (lib)

Building cryptohash-sha256-0.11.101.0 (lib)

Downloaded   zlib-0.6.2

Downloading  resolv-0.1.1.2

Installing   base16-bytestring-0.1.1.6 (all, legacy fallback)

Starting zlib-0.6.2 (lib)

Building ed25519-0.0.5.0 (lib)

Installing   base64-bytestring-1.0.0.2 (lib)

Downloaded   resolv-0.1.1.2

Downloading  echo-0.1.3

Completed    base16-bytestring-0.1.1.6 (all, legacy fallback)

Completed    base64-bytestring-1.0.0.2 (lib)

Downloaded   echo-0.1.3

Downloading  hsc2hs-0.68.4

Starting echo-0.1.3 (lib)

Downloaded   hsc2hs-0.68.4

Downloading  network-3.1.0.0

Starting hsc2hs-0.68.4 (exe:hsc2hs)

Installing   cryptohash-sha256-0.11.101.0 (lib)

Downloaded   network-3.1.0.0

Downloading  edit-distance-0.2.2.1

Completed    cryptohash-sha256-0.11.101.0 (lib)

Building echo-0.1.3 (lib)

Downloaded   edit-distance-0.2.2.1

Downloading  tar-0.5.1.0

Starting edit-distance-0.2.2.1 (lib)

Building hsc2hs-0.68.4 (exe:hsc2hs)

Downloaded   tar-0.5.1.0

Downloading  async-2.2.1

Starting tar-0.5.1.0 (lib)

Downloaded   async-2.2.1

Downloading  network-uri-2.6.1.0

Installing   echo-0.1.3 (lib)

Starting     async-2.2.1 (lib)

Installing   ed25519-0.0.5.0 (lib)

Building edit-distance-0.2.2.1 (lib)

Downloaded   network-uri-2.6.1.0

Downloading  zip-archive-0.4.1

Starting network-uri-2.6.1.0 (lib)

Completed    echo-0.1.3 (lib)

Completed    ed25519-0.0.5.0 (lib)

Building tar-0.5.1.0 (lib)

Downloaded   zip-archive-0.4.1

Downloading  HTTP-4000.3.13

Building async-2.2.1 (lib)

Building network-uri-2.6.1.0 (lib)

Downloaded   HTTP-4000.3.13

Downloading  hackage-security-0.5.3.0

Downloaded   hackage-security-0.5.3.0

Downloading  cabal-install-2.4.1.0

Downloaded   cabal-install-2.4.1.0

Installing   async-2.2.1 (lib)

Installing   edit-distance-0.2.2.1 (lib)

Completed    async-2.2.1 (lib)

Completed    edit-distance-0.2.2.1 (lib)

Installing   hsc2hs-0.68.4 (exe:hsc2hs)

Completed    hsc2hs-0.68.4 (exe:hsc2hs)

Installing   network-uri-2.6.1.0 (lib)

Completed    network-uri-2.6.1.0 (lib)

Installing   tar-0.5.1.0 (lib)

Completed    tar-0.5.1.0 (lib)

Failed to build digest-0.0.1.2. The failure occurred during the configure

step.

Build log (

/home/simonpj/.cabal/logs/ghc-8.6.4/digest-0.0.1.2-14bc149eb1d9c6a16b30ce20fef469dafeaea1cbba4f9615d23d3b4f1a2da8bd.log

):

Configuring digest-0.0.1.2...

cabal: Missing dependency on a foreign library:

* Missing (or bad) header file: zlib.h

* Missing (or bad) C library: z

This problem can usually be solved by installing the system package that

provides this library (you may need the "-dev" version). If the library is

already installed but in a non-standard location then you can use the 
flags


--extra-include-dirs= and --extra-lib-dirs= to specify where it is.If the

library file does exist, it may contain errors that are caught by the C

compiler at the preprocessing stage. In this case you can re-run configure

with the verbosity flag -v3 to see the error messages.

If the header file does exist, it may contain errors that are caught 
by the C


compiler at the preprocessing stage. In this case you can re-run configure

with the verbosity flag -v3 to see the error messages.

Failed to build zlib-0.6.2. The failure occurred during the configure 
step.


Build log (

/home/simonpj/.cabal/logs/ghc-8.6.4/zlib-0.6.2-2039caedabd32f9ed378900645b72766a462d68bf828625f67296cbc28fa173e.log

):

Configuring library for zlib-0.6.2..

cabal: Missing dependency on a foreign library:

* Missing (or bad) header file: zlib.h

* Missing (or bad) C library: z

This problem can usually be solved by installing the system package that

provides this library (you may need the "-dev" version). If the library is

already installed but in a non-standard location then you can use the 
flags


--extra-include-dirs= and --extra-lib-dirs= to specify where it is.If the

library file does exist, it may contain errors that are caught by the C

compiler at the preprocessing stage. In this case you can re-run configure

with the verbosity flag -v3 to see the error messages.

If the header file does exist, it may contain errors that are caught 
by the C


compiler at the preprocessing stage. In this case you can re-run configure

with the verbosity flag -v3 to see the error messages.

cabal: Failed to build digest-0.0.1.2 (which is required by

cabal-install-2.4.1.0). See the build log above for details.

Failed to build zlib-0.6.2 (which is required by 
cabal-install-2.4.1.0). See


the build log above for details.

*From:*Oleg Grenrus 
*Sent:* 30 May 2019 20:30
*To:* Simon Peyton Jones ; cabal-devel@haskell.org
*Subject:* Re: Installation failed

Hi again Simon,

Few points, If you run Windows 10 (Pro?), you can setup to make 
symlinks without needing administrator privileges. I used 
https://github.com/git-for-windows/

Re: Cabal install

[Oleg Grenrus]

Hi Simon,

I see, you triggered another feature/bug of cabal install, namely when 
you are in a project directory, project settings affect solving process. 
And when there's a .cabal file, it's a project.
So cabal tried to find an install plan containing local packages (that 
makes sense, if you try to install local lhs2tex for example!)


Solution is to change directory (cd) somewhere else and try again. 
(There's also cabal install -z flag feature request, -z to ignore local 
project; but it's not yet merged).


- Oleg

On 31.5.2019 11.02, Simon Peyton Jones wrote:


Thanks Oleg

my first guess is that: when working on the unsaturated type families 
paper, you did `cabal install --lib report`; or something similar. 
`report` is probably some internal library to that paper / project.


I am confident I did nothing like that. But there is a file called 
report.cabal in the directory where I did the ‘cabal install lhs2tex’ 
command.


To confirm, check what is in your 
~/.ghc/x86_64-linux-8.6.5/environments/default (or similar), is some 
`package-id report-0.1.0.0-hexhash` line there?


There is no such file:

bash$ ls ~/.ghc

ghci_history    x86_64-linux-8.9.0.20190414 
x86_64-linux-8.9.0.20190508


x86_64-linux-8.6.4  x86_64-linux-8.9.0.20190430 
x86_64-linux-8.9.0.20190527


bash$ ls ~/.ghc/x86_64-linux-8.6.4/

package.conf.d

Simon

*From:*Oleg Grenrus 
*Sent:* 30 May 2019 20:19
*To:* Simon Peyton Jones ; cabal-devel@haskell.org
*Subject:* Re: Cabal install

Hi Simon,

my first guess is that: when working on the unsaturated type families 
paper, you did `cabal install --lib report`; or something similar. 
`report` is probably some internal library to that paper / project.


In that case, you are hitting the unfortunate cabal bug [1].

To confirm, check what is in your 
~/.ghc/x86_64-linux-8.6.5/environments/default (or similar), is some 
`package-id report-0.1.0.0-hexhash` line there? If so, the simplest 
fix is to remove that environment file.


- [1] https://github.com/haskell/cabal/issues/5888 
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fcabal%2Fissues%2F5888=02%7C01%7Csimonpj%40microsoft.com%7C5a4d4dc3dc214b29d8f408d6e533b91b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636948407671672464=OH3R%2Fl9xP6d2w8OUQ8V%2FUa%2Bp%2FEpDeqyy%2FWWBxTJ7Q%2BQ%3D=0>https://github.com/haskell/cabal/issues/5559

<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fcabal%2Fissues%2F5559=02%7C01%7Csimonpj%40microsoft.com%7C5a4d4dc3dc214b29d8f408d6e533b91b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636948407671682461=%2Fo%2FL6ZWU%2Bt2fA1CDGqjHL7RU1FFHGbIJacPzLNctZyE%3D=0>

Cheers,
Oleg

On 30.5.2019 16.50, Simon Peyton Jones wrote:

Dear friendly Cabal folk

Here’s what happened to me today

bash$ cabal install lhs2tex

cabal: Could not resolve dependencies:

[__0] next goal: report (user goal)

[__0] rejecting: report-0.1.0.0 (conflict: requires
UnsaturatedTypeFamilies)

[__0] fail (backjumping, conflict set: report)

After searching the rest of the dependency tree exhaustively,
these were the

goals I've had most trouble fulfilling: report

Crumbs.  What is ‘report’?  Why does it need
UnsaturatedTypeFamilies?   I’m totally lost.

Then, in an inspired moment, I thought to change to a different
directory, ~/tmp.

Then quite different things happened – it downloaded and built
relevant libraries.

I think that there just happened to be a .cabal file in the
original directory I was in at the time.  That appears to affect
what ‘cabal install’ does in a truly radical way.

My point is this: this is terribly confusing for the user (at
least for this on).   I’d be shocked if ‘apt install blah’ behaved
utterly differently in different directories.  I’m going to make a
little empty directory somewhere, and cd to it before invoking
cabal in future.  But that just feels like a workaround, not a
solution.

I’m not saying it’s wrong – just giving you a data point that it
had one user completely stumped

Simon



___

cabal-devel mailing list

cabal-devel@haskell.org  <mailto:cabal-devel@haskell.org>

http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel  
<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcabal-devel=02%7C01%7Csimonpj%40microsoft.com%7C5a4d4dc3dc214b29d8f408d6e533b91b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636948407671692458=vRr6UoW69Y0U7rGrYHm1XtbAH2jlFsArh21E7i0o6ko%3D=0>

___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: Installation failed

[Oleg Grenrus]

Hi again Simon,

Few points, If you run Windows 10 (Pro?), you can setup to make symlinks 
without needing administrator privileges. I used 
https://github.com/git-for-windows/git/wiki/Symbolic-Links guide. 
Unfortunately I don't remember all the details I did (i.e. if the guide 
is complete), but enabling Developer Mode is easy to forget.


About installing and symlinking:
- `cabal update-config` should populate your ~/.cabal/config with new 
default configuration. which will have install-dir: there too. You can 
also manually edit it to add the new configuration option.
- Most of install woes are fixed in March [1], but there weren't a 
release with those fixes.


- [1] https://github.com/haskell/cabal/pull/5870

Cheers,
Oleg

On 30.5.2019 16.57, Simon Peyton Jones wrote:


Dear Cabal developers

More woe:

simonpj@MSRC-3645512:~$ cabal install lhs2tex

Resolving dependencies...

Up to date

cabal: installdir is not defined. Set it in your cabal config file or use

--installdir=

In the olden days, didn’t cabal install by default in ~/.cabal/bin?

Never mind, let’s do what it asks:

simonpj@MSRC-3645512:~$ cabal install lhs2tex --installdir=/usr/bin

Resolving dependencies...

Up to date

Symlinking 'lhs2TeX'

/usr/bin/lhs2TeX: createSymbolicLink: permission denied (Permission 
denied)


Darn: I need to be super-user.  Fine:

simonpj@MSRC-3645512:~$ sudo cabal install lhs2tex --installdir=/usr/bin

[sudo] password for simonpj:

cabal: unrecognized 'install' option `--installdir=/usr/bin'

OK _/now/_ I really am stumped.  It asked me to provide that option, 
and now it says it’s unrecognised.


(This is in a bash shell running in emacs, if it makes a difference.)

What next?

Thanks

Simon


___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: Cabal install

[Oleg Grenrus]

Hi Simon,

my first guess is that: when working on the unsaturated type families 
paper, you did `cabal install --lib report`; or something similar. 
`report` is probably some internal library to that paper / project.


In that case, you are hitting the unfortunate cabal bug [1].

To confirm, check what is in your 
~/.ghc/x86_64-linux-8.6.5/environments/default (or similar), is some 
`package-id report-0.1.0.0-hexhash` line there? If so, the simplest fix 
is to remove that environment file.


- [1] https://github.com/haskell/cabal/issues/5888 
https://github.com/haskell/cabal/issues/5559


Cheers,
Oleg

On 30.5.2019 16.50, Simon Peyton Jones wrote:


Dear friendly Cabal folk

Here’s what happened to me today

bash$ cabal install lhs2tex

cabal: Could not resolve dependencies:

[__0] next goal: report (user goal)

[__0] rejecting: report-0.1.0.0 (conflict: requires 
UnsaturatedTypeFamilies)


[__0] fail (backjumping, conflict set: report)

After searching the rest of the dependency tree exhaustively, these 
were the


goals I've had most trouble fulfilling: report

Crumbs.  What is ‘report’?  Why does it need 
UnsaturatedTypeFamilies?   I’m totally lost.


Then, in an inspired moment, I thought to change to a different 
directory, ~/tmp.


Then quite different things happened – it downloaded and built 
relevant libraries.


I think that there just happened to be a .cabal file in the original 
directory I was in at the time. That appears to affect what ‘cabal 
install’ does in a truly radical way.


My point is this: this is terribly confusing for the user (at least 
for this on).   I’d be shocked if ‘apt install blah’ behaved utterly 
differently in different directories.  I’m going to make a little 
empty directory somewhere, and cd to it before invoking cabal in 
future.  But that just feels like a workaround, not a solution.


I’m not saying it’s wrong – just giving you a data point that it had 
one user completely stumped


Simon


___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: Upgrading Stack to Cabal 2.2

[Oleg Grenrus]

Good point. There aren't ReadP-parser for SPDX.License, so no Text
instance either.
But there is `Distribution.Pretty.Pretty` instance (`prettyShow`).

- Oleg


On 20.02.2018 20:28, Michael Snoyman wrote:
> Alright, I've updated the PR to use `Either SPDX.License License`:
>
> https://github.com/commercialhaskell/stack/pull/3878/commits/6679aafe99a087dd6aac341fce965f4067e1be77
>
> The only difference from your description that I ran into is that
> there's no Text instance for SPDX.License, meaning instead of:
>
>     either display display
>
> I ended up with
>
>     display . either licenseFromSPDX id
>
> Is it intentional that there is no Text instance for SPDX.License?
>
> On Tue, Feb 20, 2018 at 8:02 PM, Oleg Grenrus <oleg.gren...@iki.fi
> <mailto:oleg.gren...@iki.fi>> wrote:
>
> 1. The InstalledPackageInfo license field is also `Either SPDX.License
> License` [1] and you can get a list of IPIs conviently with
> `HcPkg.dump` [2]
> 2. It's up to you, if `Text` is enough, go for it. In the future you
> might want to provide some license reports, where you'll need
> structured
> license information, but then "reverting" `TextualLicense` will be a
> type-directed, so it's up to you.
>
> Oleg
>
>
> -
> 
> https://github.com/haskell/cabal/blob/32fea06a1023a507d7dc16b29f542538c0b55e46/Cabal/Distribution/Types/InstalledPackageInfo.hs#L50
> 
> <https://github.com/haskell/cabal/blob/32fea06a1023a507d7dc16b29f542538c0b55e46/Cabal/Distribution/Types/InstalledPackageInfo.hs#L50>
> -
> 
> https://github.com/haskell/cabal/blob/32fea06a1023a507d7dc16b29f542538c0b55e46/Cabal/Distribution/Simple/Program/HcPkg.hs#L246
> 
> <https://github.com/haskell/cabal/blob/32fea06a1023a507d7dc16b29f542538c0b55e46/Cabal/Distribution/Simple/Program/HcPkg.hs#L246>
>
>
> On 20.02.2018 19:45, Michael Snoyman wrote:
> > I'm sorry, I'm not quite sure I understand your recommendation. Are
> > you saying that I should ideally replace all usages of `License` in
> > the Stack codebase with `Either SPDX.License License`? That _should_
> > be possible, the only questions I'd have are:
> >
> > 1. We additionally grab license info from the GHC package dump.
> Would
> > there be any problem parsing that license field into the old License
> > data type and storing as Right?
> > 2. If we're going to have to treat this as arbitrary text anyway, is
> > there any reason not to represent it as `newtype TextualLicense =
> > TextualLicense Text` or similar, and convert immediately with
> `display`?
> >
> > On Tue, Feb 20, 2018 at 6:12 PM, Oleg Grenrus
> <oleg.gren...@iki.fi <mailto:oleg.gren...@iki.fi>
> > <mailto:oleg.gren...@iki.fi <mailto:oleg.gren...@iki.fi>>> wrote:
> >
> >     Hi Michael,
> >
> >     thanks for your comments!
> >
> >     - The allBuildInfo change is
> >   
>  
> https://github.com/haskell/cabal/commit/8fc10320a5dc4898927c84ad6a2dce7965ef30db
> 
> <https://github.com/haskell/cabal/commit/8fc10320a5dc4898927c84ad6a2dce7965ef30db>
> >   
>  
> <https://github.com/haskell/cabal/commit/8fc10320a5dc4898927c84ad6a2dce7965ef30db
> 
> <https://github.com/haskell/cabal/commit/8fc10320a5dc4898927c84ad6a2dce7965ef30db>>,
> >     I agree with Herbert on this. New `allBuildInfo`
> implementation is
> >     correct given the name. There was even a TODO to make that
> change.
> >     `reallyAllBuildInfo` would been silly. I also didn't felt ok
> to change
> >     the type to `Traversal` (we have lenses, please try out them
> too and
> >     tell if something is missing!). We'll highlight the change
> in the
> >     changelog, as it's easy to miss.
> >
> >     - The lack of SPDX changelog entry is my bad. It was a series of
> >     patches, and the changelog + manual update is still not
> done. I try to
> >     summarise:
> >     - `cabal-version: 2.2` files use SPDX expression syntax for
> >     `license: ` field. PackageDescription's licenseRaw will be
> Left expr,
> >     expr :: Distribution.SPDX.License.License
> >     - `cabal-version: 2.0` files still use old `License`
> syntax and
> >     type, licenseRaw is `Right l`, l :: Distribution.License.License
> >     - I recommend treating the field as opaque. You can `either
> >     display
> >     display` to 

Re: Upgrading Stack to Cabal 2.2

[Oleg Grenrus]

1. The InstalledPackageInfo license field is also `Either SPDX.License
License` [1] and you can get a list of IPIs conviently with `HcPkg.dump` [2]
2. It's up to you, if `Text` is enough, go for it. In the future you
might want to provide some license reports, where you'll need structured
license information, but then "reverting" `TextualLicense` will be a
type-directed, so it's up to you.

Oleg


-
https://github.com/haskell/cabal/blob/32fea06a1023a507d7dc16b29f542538c0b55e46/Cabal/Distribution/Types/InstalledPackageInfo.hs#L50
-
https://github.com/haskell/cabal/blob/32fea06a1023a507d7dc16b29f542538c0b55e46/Cabal/Distribution/Simple/Program/HcPkg.hs#L246


On 20.02.2018 19:45, Michael Snoyman wrote:
> I'm sorry, I'm not quite sure I understand your recommendation. Are
> you saying that I should ideally replace all usages of `License` in
> the Stack codebase with `Either SPDX.License License`? That _should_
> be possible, the only questions I'd have are:
>
> 1. We additionally grab license info from the GHC package dump. Would
> there be any problem parsing that license field into the old License
> data type and storing as Right?
> 2. If we're going to have to treat this as arbitrary text anyway, is
> there any reason not to represent it as `newtype TextualLicense =
> TextualLicense Text` or similar, and convert immediately with `display`?
>
> On Tue, Feb 20, 2018 at 6:12 PM, Oleg Grenrus <oleg.gren...@iki.fi
> <mailto:oleg.gren...@iki.fi>> wrote:
>
> Hi Michael,
>
> thanks for your comments!
>
> - The allBuildInfo change is
> 
> https://github.com/haskell/cabal/commit/8fc10320a5dc4898927c84ad6a2dce7965ef30db
> 
> <https://github.com/haskell/cabal/commit/8fc10320a5dc4898927c84ad6a2dce7965ef30db>,
> I agree with Herbert on this. New `allBuildInfo` implementation is
> correct given the name. There was even a TODO to make that change.
> `reallyAllBuildInfo` would been silly. I also didn't felt ok to change
> the type to `Traversal` (we have lenses, please try out them too and
> tell if something is missing!). We'll highlight the change in the
> changelog, as it's easy to miss.
>
> - The lack of SPDX changelog entry is my bad. It was a series of
> patches, and the changelog + manual update is still not done. I try to
> summarise:
>     - `cabal-version: 2.2` files use SPDX expression syntax for
> `license: ` field. PackageDescription's licenseRaw will be Left expr,
> expr :: Distribution.SPDX.License.License
>     - `cabal-version: 2.0` files still use old `License` syntax and
> type, licenseRaw is `Right l`, l :: Distribution.License.License
>     - I recommend treating the field as opaque. You can `either
> display
> display` to show it
>    - Next best choice is to use `SPDX.License` as in that
> direction
> conversion is lossless (licenseToSPDX), but have to workaround lack of
> e.g. `OtherLicense` as a concept (IIRC it's converted to
> LicenseRef:OtherLicense which is valid SPDX-License-Id). This might be
> necessary if you plan to read (human readable) text back.
>
> Oleg
>
> On 20.02.2018 15:47, Michael Snoyman wrote:
> > Hi all,
> >
> > Oleg mentioned to me on Reddit that a 2.2 branch has been cut for
> > Cabal, and recommended we try to upgrade Stack to it. I'm sharing
> > information here on that process in case it's useful to others,
> either
> > as feedback on the API changes, or help for others going through
> > similar upgrades. If anyone would rather that I do or do not
> post such
> > reports in the future, let me know.
> >
> > I've opened a PR for this change[1], which currently is a single
> > commit[2]. As you can see from the change to stack.yaml[3], I needed
> > to refer to the commit of Cabal in question, and turn on
> `allow-newer`
> > for some packages (cabal-doctest and http-api-data) with restrictive
> > upper bounds on Cabal. Both of these packages compiled without
> issue.
> >
> > No change was necessary to Stack's Setup.hs file.
> >
> > Most of the changes so far were compile-time errors, which is a Good
> > Thing. Changes I had to make:
> >
> > * The build type is no longer a Maybe field. (As a user: this is a
> > nice change, no longer a need to guess about what a Nothing
> value means.)
> > * There are now two License types, the original one and the SPDX
> > variant. I don't understand what this change is about, some further
> > explanation in the docs or the ChangeLog would definitely be
&g

Re: Upgrading Stack to Cabal 2.2

[Oleg Grenrus]

Hi Michael,

thanks for your comments!

- The allBuildInfo change is
https://github.com/haskell/cabal/commit/8fc10320a5dc4898927c84ad6a2dce7965ef30db,
I agree with Herbert on this. New `allBuildInfo` implementation is
correct given the name. There was even a TODO to make that change.
`reallyAllBuildInfo` would been silly. I also didn't felt ok to change
the type to `Traversal` (we have lenses, please try out them too and
tell if something is missing!). We'll highlight the change in the
changelog, as it's easy to miss.

- The lack of SPDX changelog entry is my bad. It was a series of
patches, and the changelog + manual update is still not done. I try to
summarise:
    - `cabal-version: 2.2` files use SPDX expression syntax for
`license: ` field. PackageDescription's licenseRaw will be Left expr,
expr :: Distribution.SPDX.License.License
    - `cabal-version: 2.0` files still use old `License` syntax and
type, licenseRaw is `Right l`, l :: Distribution.License.License
    - I recommend treating the field as opaque. You can `either display
display` to show it
   - Next best choice is to use `SPDX.License` as in that direction
conversion is lossless (licenseToSPDX), but have to workaround lack of
e.g. `OtherLicense` as a concept (IIRC it's converted to
LicenseRef:OtherLicense which is valid SPDX-License-Id). This might be
necessary if you plan to read (human readable) text back.

Oleg

On 20.02.2018 15:47, Michael Snoyman wrote:
> Hi all,
>
> Oleg mentioned to me on Reddit that a 2.2 branch has been cut for
> Cabal, and recommended we try to upgrade Stack to it. I'm sharing
> information here on that process in case it's useful to others, either
> as feedback on the API changes, or help for others going through
> similar upgrades. If anyone would rather that I do or do not post such
> reports in the future, let me know.
>
> I've opened a PR for this change[1], which currently is a single
> commit[2]. As you can see from the change to stack.yaml[3], I needed
> to refer to the commit of Cabal in question, and turn on `allow-newer`
> for some packages (cabal-doctest and http-api-data) with restrictive
> upper bounds on Cabal. Both of these packages compiled without issue.
>
> No change was necessary to Stack's Setup.hs file.
>
> Most of the changes so far were compile-time errors, which is a Good
> Thing. Changes I had to make:
>
> * The build type is no longer a Maybe field. (As a user: this is a
> nice change, no longer a need to guess about what a Nothing value means.)
> * There are now two License types, the original one and the SPDX
> variant. I don't understand what this change is about, some further
> explanation in the docs or the ChangeLog would definitely be
> appreciated. But hacking my way through the types seems to have worked.
> * Parsing a package description now works on a ByteString instead of a
> String. This allowed me to remove some UTF8 conversion and
> BOM-stripping code, which is very nice.
> * The new parsing API exposes the cabal file version when that
> prevented the parse (at least, that's my understanding). The changes
> to accommodate the new API were relatively trivial, so another +1 here.
> * Also: getting file position information for warnings and errors is
> _very_ nice. +1
>
> I haven't done extensive testing yet, but I've so far only found one
> bug due to runtime changes: the behavior of allBuildInfo has changed
> to now include non-buildable components. This resulted in some
> confusion until I reviewed the changelog more closely. If I could make
> a request, it would be that, in the future, new runtime behavior come
> with a new function name, to convert runtime errors into compile time
> errors. This was _not_ a particularly difficult issue to work around
> though, in large part thanks to the changelog.
>
> I'll continue testing this branch of Stack. Our plans are to merge
> this to master, and release Stack 1.7.0 close to the Cabal 2.2 release
> date.
>
> Michael
>
> [1] https://github.com/commercialhaskell/stack/pull/3878/files
> [2]
> https://github.com/commercialhaskell/stack/pull/3878/commits/a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5
> [3]
> https://github.com/commercialhaskell/stack/pull/3878/commits/a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5#diff-fafd0cdcd559a7b124cc61c29413fb54
>
>
> ___
> cabal-devel mailing list
> cabal-devel@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel




signature.asc
Description: OpenPGP digital signature
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: Gearing up for the 2.2 release

[Oleg Grenrus]

I had a good success with completing a lot of parser work around Christmas, 
still on my todo list are:

- rewriting InstalledPackageInfo parser using new (parsec) framework, 
which is (soft) prerequisite to
- changing license field to use SPDX expressions

SPDX types are already merged, so there aren't much left, expect 2-3 PRs early 
next year. 

I'm heading off to no-keyboard place.

- Oleg

Sent from my iPhone

> On 15 Dec 2017, at 18.40, Mikhail Glushenkov  
> wrote:
> 
> Hi *,
> 
> It is time to start planning for the 2.2 release of
> Cabal/cabal-install. The original plan was to do it before the end of
> the year, however, given the current state of HEAD and the fact that
> GHC 8.4 is going to be released in February, I think it won't be a
> tragedy if we delay 2.2 a little. My current plan is to cut the 2.2
> branch around January 15th, and make the release 2-3 weeks after that.
> So please hurry if there's something you absolutely want to get into
> 2.2.
> 
> Current release blockers/stuff that I really want to see included:
> 
> * Herbert's work on the forwards-compat scheme
> (https://github.com/haskell/cabal/issues/4899)
> * Duncan's target package names stuff
> (https://github.com/haskell/cabal/pull/4889)
> * Oleg's remaining parser PRs and SPDX work.
> * Some other currently unmerged PRs that are not marked blocked or are
> easy to get into mergeable shape.
> 
> 
> Cheers,
> Mikhail
> ___
> cabal-devel mailing list
> cabal-devel@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: mutex-flags

[Oleg Grenrus]

Hi,

I proposed multiway flags about a year ago [1].
With that you could write:

flag xx
  values: a, b, c, d
 
if flag(xx == a)
  build-depends: xx-a
if flag(xx == b)
  build-depends: xx-b
if flag(xx == c)
  build-depends: xx-c
if flag(xx == d)
  build-depends: xx-d

The benefits over your proposal, is that there's only one flag!

The alternatives mentioned in the issue [1] consider only automatic flags,
but now as I think about, manual multiway flags can be useful too.

---

For complex "multiway" selection example see:

http://hackage.haskell.org/package/functor-classes-compat-1/functor-classes-compat.cabal

The idea is that with two flags (transformers-1 and transformers-2) you have
already 4 combinations, so you don't need 4 flags.
That's not intuitive interface for manual flags though.

(There the "elif" syntax would help, which I'll add to Cabal for GHC-8.4)

---

Another way to write "mutex" is (with three flags: a, b, c):

  -- at least one:
  if !(flag(a) || flag(b) || flag(c))
  -- at most one:
  if flag(a) && flag(b)
 build-depends: base<0
  if flag(a) && flag(c)
 build-depends: base<0
  if flag(b) && flag(c)
 build-depends: base<0

That's tedious to go thru all pairs, but quite straightforward.
And can live in a separate block from where the actual flag-logic is
defined.

The same trick can be used with two-flags for three options:

if flag(xx-1)
  if flag(xx-2)
-- option 1
  else
-- option 2
else
  if flag(xx-2)
-- option 3
  else
build-depends: base<0

It's also discussed to add explicit

   fail: Unsupported configuration

so we don't need to use unsatisfiable "base<0" constraint.

- Oleg

[1]: https://github.com/haskell/cabal/issues/3526

On 19.07.2017 04:50, Lee John wrote:
> I think the mutex flags might be needed. For example, if my program use 
> accelerate and I want my program can use both of cuda, llvm, (etc) as the 
> backend for accelerating, I need to write a lot of if-statements in cabal 
> file to control that there will be only one backend to be used. So I think 
> that mutex-flags might be useful.
>
> For example:
>
> …
> flag a
> default: False
> flag b
> default: False
> flag c
> default: False
> flag d
> default: False
> ...
> exec…
> …
> if flag(a) && !flag(b) && !flag(c) && !flag(d)
>   build-depends: xx-a
>
> …
> if !flag(a) && flag(b) && !flag(c) && !flag(d)
>   build-depends: xx-b
>
> …
> if !flag(a) && !flag(b) && flag(c) && !flag(d)
>   build-depends: xx-c
>
> …
> if !flag(a) && !flag(b) && !flag(c) 
>   build-depends: xx-d
> …
>
> The above codes are also hard to maintain or extend. Following codes will 
> better.
>
> …
> flag a
> default: False
> flag b
> default: False
> flag c
> default: False
> flag d
> default: False
> mutex 
> flags: a b c d
> default: d
> …
>
> if flag(a)
> build-depends: xx-a
>
> if flag(b)
> build-depends: xx-b
>
> if flag(c)
> build-depends: xx-c
>
> if flag(d)
> build-depends: xx-d
> ...
> ___
> cabal-devel mailing list
> cabal-devel@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel




signature.asc
Description: OpenPGP digital signature
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: Opening up Cabal development

[Oleg Grenrus]

> On 14 Jul 2016, at 09:54, Edward Z. Yang  wrote:
> 
> Excerpts from Herbert Valerio Riedel's message of 2016-07-13 23:40:06 -0700:
>> I.e. write up a specification/proposal outlining motivation (i.e. what
>> problem does this solve), specify what the changes are exactly (syntax &
>> semantics), what the consequences are, and so on.
>> 
>> Then we inevitably need some criteria to decide whether a proposal is
>> accepted and approved for implementation. This could be formally in the
>> hands of the core library committee together with the Hackage trustees
>> (since we do have quite some experience with .cabal files and care a lot
>> about the Hackage ecosystem).
> 
> Why can't we release experimental changes to the Cabal specification?
> Neither setup-depends nor convenience libraries went through any formal
> proposal mechanism.  If a feature is good people will start using it
> and we will have to continue supporting it.  If a feature is bad/not
> useful we can yank it from the next release; anyone using an
> experimental feature like this isn't trying to maximize their
> Cabal compatibility anyway.  And any change to the format with
> cabal-install can't parse is not going to be supportable via
> custom-setup anyway.

You gave a reason yourself:
- Can we parse all of Hackage?

With my industrial hat on, I don’t like the idea that I might need older Cabal,
to be able to install some package. OTOH new-build could install older Cabal.
So we’d need to maintain older Cabals, to be build able with newer GHCs,
that’s not fun, but not impossible.

I agree, that we could have discussed setup-depends more,
hopefully no-one disagrees about them (and dcoutts took very conservative 
approach there).
Also taking them out of Cabal, doesn’t mean that package becomes unbuildable,
there will be just more luck involved.

About convenience libraries I agree even more. We should discussed them more.
There are questions I’d might to ask, but I guess it too late

Or maybe not too late, but for another thread:
what is convenience library name clashes with the library on package,
say I define convenience library fancylib-lens, which is on Hackage, but maybe 
also after I made my package?
I guess, some shadowing happens? Is there a warning?

But we have quite formal feeling proposals about `provides`,
and `or-dependencies / multi-way-flag / depends`, and
formal process would help to get them thru (or say no, with an explanation)

> 
> So how about this script, which is how web standards work:
> 
>Cabal changes need to be informally proposed and discussed.
>But the advancer can also write a PR and get it merged in
>as an experimental extension, to be trialed for the next
>major release series.  Eventually it gets standardized.
> 
> Edward

About the original topic, I’d require “ a history of quality contributions”, so 
something between (2) or (3).
I don’t like many rules, also making fair but non-abusable ones is difficult, 
but as we have this conversation,
the outcome should be well defined (also how we change the rules).
As with (2) does every accepted PR counts, like single character typo fix in 
the documentation?
And I don’t know how to define “quality contribution” :(

(Maybe I’m just to scared about dramas happened elsewhere)

Related to this, a thought I had for some time:
I’d like to split Cabal and cabal-install repositories.

Pros:
- `cabal-install` can be much more liberal in giving out commit bits, as you 
cannot make too much damage here.
- we already have `hackage-security` as a dependency between them.
- the CI setup could be simplified, resulting into
- their tests could do more things: `Cabal` parses all `Hackage`, changes to 
`cabal-install` doesn’t need to do it,
  and vice-versa, fixing ui of cabal-install doesn’t need to do package tests 
of Cabal.
- their other processes could be different too.

Cons: Simultaneous development is almost impossible. And this is almost a 
show-stopper.
- `cabal-install` would need to lag one release behind `Cabal` (development 
agains released `Cabal`).
  This could work as `Setup.hs` should work to install packages requiring newer 
Cabal (isn’t it how it works nowadays?).
  There will be a problem when newer `Cabal` won’t accept build-plan created by 
solver
  in older `cabal-install` (proposals mentioned above), but I hope it won’t be 
a huge issue.
- To make this work we’d need to release more Cabal major versions,
  so there aren’t many breaking and intrusive changes accumulating. But that’s 
good thing, isn’t it?

Or it could be a quality win to separate them. After all `cabal-install` is not 
the only consumer of `Cabal`.
`stack` uses it very limitedly atm though (i.e. to extract dependencies and 
maybe verify install plan?)
I don’t know what `ghc-pkg` does.

IMHO we should develop Cabal-the-library with highest standards (starting with 
having detailed CHANGELOG) for library development.
Now we might have been too focused on 

Re: I reorged labels on Cabal's GitHub

[Oleg Grenrus]

Great, it looks awesome.

Issue template is great idea as well. (for ones who aren’t familiar: 
https://github.com/blog/2111-issue-and-pull-request-templates 
)
(I’m +1 for having GitHub stuff under .github/ directory)

The issue template could ask for
- Cabal/cabal-install/ghc versions
- ask to run cabal-install with -v2 flag and add that to the issue?

with quick glance it doesn’t apply to many issues, but when it does, it would 
be helpful.


- Oleg

> On 12 Jul 2016, at 23:48, Edward Z. Yang  wrote:
> 
> Excerpts from Oleg Grenrus's message of 2016-07-12 12:45:05 -0700:
>> 
>>> On 12 Jul 2016, at 18:42, Edward Z. Yang  wrote:
>>> 
>>> Excerpts from Oleg Grenrus's message of 2016-07-12 04:03:43 -0700:
 Looks good indeed!
 
 I have few questions:
 - what is purpose of `paging:*` labels, to help people see issues they are 
 interested in? How it’s different from assignees (which can be multiple)?
>>> 
>>> Beyond what Mikhail stated:
>>> 
>>>   - Multiple people can be paged, only one assigned
>> Yes you can. 
>> https://github.com/blog/2178-multiple-assignees-on-issues-and-pull-requests 
>> 
> 
> Haha! Learned something today.
> 
>>>   - I can put more metadata in the tag name than assignable
>>> (to help people decide who to page)
>> Ah, page as in ping. That meaning I always find weird (and don’t remember).
>> 
>>> summon (someone) over a public address system, so as to pass on a message
>> 
>> IMHO multiple assignment would work better as it actually sends notification 
>> (if one choose to receive such).
>> 
>> Yet, you’re right, deciding whom to page/assign is often non-obvious. Not 
>> sure if few-word description if any helpful. (e.g. whom to contact on 
>> hackage-security problems, I’m actually unsure whether it’s edsko or 
>> dcoutts, or on something else...).
> 
> OK, I am convinced we should drop it.
> 
> Let's do this:
> 
>- To page someone, just write CC @blah in the message
>- We should add an issue template that requests you
>  CC someone and explains who you might want to CC
> 
 - why “bug” has “ezyang planning to delete this tag”. I’d prefer to have 
 “type: bug” and other “type:*” labels as:  “type: discuss”, “type: 
 enhancement”, “type: question”, and maybe more as e.g. stack has 
 https://github.com/commercialhaskell/stack/labels 
 
>>> 
>>> OK, the tag served it's purpose! I planned to delete it because there
>>> are lots of bugs in the issues tracker and no one has been methodically
>>> tagging them bug or not, so it seemed that the tag was just not that
>>> helpful.  Just look at Stack's issues list: 
>>> https://github.com/commercialhaskell/stack/issues
>>> who is tagging things as bugs!
>> 
>> If we go for type:* tags, I’ll help with triaging all issues with type:* tag.
> 
> OK, fine. I've reorged accordingly.
> 
>>> 
>>> discuss/enhancement/question are useful and I support tags for them.
>>> Presently we have "priority: enhancement" but we can rename that as
>>> needed.
>> 
>> I’d like priorities to have a total-order. high > low is obvious, but what 
>> about enhancement and user-question? I’d change latter two into type:*, and 
>> maybe later introduce third priority level if we feel we need one.
> 
> Added.
> 
 - how priority labels interact with milestones?
>>> 
>>> Agreed with Mikhail; priority within milestone.
>>> 
 - Should we add “pr welcome” or “awaiting pr” for issues which are 
 discussed, but nobody have interest or time implementing right away (will 
 help new contributors especially when combined with `meta: easy`)
>>> 
>>> Sure! I wonder, however; for tickets that are tagged this way, I feel
>>> the onus is on us to write a clear spec at the top of the bug for what
>>> is desired (even better: link to a commit with a test!)  Will help
>>> contributors a lot.
>> 
>> Yes, we should help as much as possible. I’d tag only “clear” issues, and 
>> add a comment that I can help with it, if there are some questions (or/and 
>> assign it to myself).
>> 
>> Also I forgot to ask about "attention: please-merge”. What’s it purpose, to 
>> tag PRs that author thinks are amerceable? IMHO the comment is enough, and 
>> also would work for external-contributors, who **cannot** tag issues/prs. 
>> (This is the reason why I got push-rights in the first place, I’m still 
>> quite uncomfortable pushing changes myself).
> 
> Dropped it.
> 
>> And what’s the idea behind “attention: regression”? How it’s different from 
>> a `type: bug` (its special case of a bug, but does it matter that much. 
>> Regressions could be critical or not, so priority tag, with type:bug would 
>> be enough?)
> 
> Regression is in here because we used to have a regression tag. I'll
> reclassify them.
> 
>> E.g.
>>

Re: I reorged labels on Cabal's GitHub

[Oleg Grenrus]

> On 12 Jul 2016, at 18:42, Edward Z. Yang  wrote:
> 
> Excerpts from Oleg Grenrus's message of 2016-07-12 04:03:43 -0700:
>> Looks good indeed!
>> 
>> I have few questions:
>> - what is purpose of `paging:*` labels, to help people see issues they are 
>> interested in? How it’s different from assignees (which can be multiple)?
> 
> Beyond what Mikhail stated:
> 
>- Multiple people can be paged, only one assigned
Yes you can. 
https://github.com/blog/2178-multiple-assignees-on-issues-and-pull-requests 



>- I can put more metadata in the tag name than assignable
>  (to help people decide who to page)
Ah, page as in ping. That meaning I always find weird (and don’t remember).

> summon (someone) over a public address system, so as to pass on a message

IMHO multiple assignment would work better as it actually sends notification 
(if one choose to receive such).

Yet, you’re right, deciding whom to page/assign is often non-obvious. Not sure 
if few-word description if any helpful. (e.g. whom to contact on 
hackage-security problems, I’m actually unsure whether it’s edsko or dcoutts, 
or on something else...).

> 
> But it's an experiment. If it's not useful we can delete the tags.
> 
>> - why “bug” has “ezyang planning to delete this tag”. I’d prefer to have 
>> “type: bug” and other “type:*” labels as:  “type: discuss”, “type: 
>> enhancement”, “type: question”, and maybe more as e.g. stack has 
>> https://github.com/commercialhaskell/stack/labels 
>> 
> 
> OK, the tag served it's purpose! I planned to delete it because there
> are lots of bugs in the issues tracker and no one has been methodically
> tagging them bug or not, so it seemed that the tag was just not that
> helpful.  Just look at Stack's issues list: 
> https://github.com/commercialhaskell/stack/issues
> who is tagging things as bugs!

If we go for type:* tags, I’ll help with triaging all issues with type:* tag.

> 
> discuss/enhancement/question are useful and I support tags for them.
> Presently we have "priority: enhancement" but we can rename that as
> needed.

I’d like priorities to have a total-order. high > low is obvious, but what 
about enhancement and user-question? I’d change latter two into type:*, and 
maybe later introduce third priority level if we feel we need one.

> 
>> - how priority labels interact with milestones?
> 
> Agreed with Mikhail; priority within milestone.
> 
>> - Should we add “pr welcome” or “awaiting pr” for issues which are 
>> discussed, but nobody have interest or time implementing right away (will 
>> help new contributors especially when combined with `meta: easy`)
> 
> Sure! I wonder, however; for tickets that are tagged this way, I feel
> the onus is on us to write a clear spec at the top of the bug for what
> is desired (even better: link to a commit with a test!)  Will help
> contributors a lot.

Yes, we should help as much as possible. I’d tag only “clear” issues, and add a 
comment that I can help with it, if there are some questions (or/and assign it 
to myself).

Also I forgot to ask about "attention: please-merge”. What’s it purpose, to tag 
PRs that author thinks are amerceable? IMHO the comment is enough, and also 
would work for external-contributors, who **cannot** tag issues/prs. (This is 
the reason why I got push-rights in the first place, I’m still quite 
uncomfortable pushing changes myself).

And what’s the idea behind “attention: regression”? How it’s different from a 
`type: bug` (its special case of a bug, but does it matter that much. 
Regressions could be critical or not, so priority tag, with type:bug would be 
enough?)

E.g.
is:open label:"priority: high" label:"bug (ezyang is planning to delete 
this tag)" milestone:"Cabal 1.26"
filter
 
https://github.com/haskell/cabal/issues?utf8=%E2%9C%93=is%3Aopen%20label%3A%22priority%3A%20high%22%20label%3A%22bug%20(ezyang%20is%20planning%20to%20delete%20this%20tag)%22%20milestone%3A%22Cabal%201.26%22%20
 


shows not that many.

OTOH there are 210 open issues (is:open is:issue no:milestone) without any 
milestone. Should we put them all into _|_ - milestone, and then promote to 
version milestones, when the discussion advanced enough we know when we want to 
release them (the soonest, or the latest?). As Cabal-1.26 165 open issues 
indicates, it’s more like “the soonest”, at least at this point.

cabal-install-1.24.0.1 has 12 open issues, should we create 
cabal-install-1.24.1 -milestone and move them there?

- Oleg


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cabal-devel mailing list
cabal-devel@haskell.org

Re: I reorged labels on Cabal's GitHub

[Oleg Grenrus]

Looks good indeed!

I have few questions:
- what is purpose of `paging:*` labels, to help people see issues they are 
interested in? How it’s different from assignees (which can be multiple)?
- why “bug” has “ezyang planning to delete this tag”. I’d prefer to have “type: 
bug” and other “type:*” labels as:  “type: discuss”, “type: enhancement”, 
“type: question”, and maybe more as e.g. stack has 
https://github.com/commercialhaskell/stack/labels 

- how priority labels interact with milestones?
- Should we add “pr welcome” or “awaiting pr” for issues which are discussed, 
but nobody have interest or time implementing right away (will help new 
contributors especially when combined with `meta: easy`)

- Oleg

> On 11 Jul 2016, at 08:09, Mikhail Glushenkov  > wrote:
> 
> Hi,
> 
> On 11 July 2016 at 06:37, Edward Z. Yang  > wrote:
>> If you hate it I can change it back but give it a try for now.
>> If the "component" prefix in "component: solver" is too long we could go for
>> something like "C-solver" but I think that is less transparent.
> 
> Thanks, looks much better than the previous version.
> 
> Re: the "specification" tag, I think it's supposed to mark proposed
> changes to the .cabal file format and GHC/Cabal interaction (i.e. the
> Cabal spec).
> ___
> cabal-devel mailing list
> cabal-devel@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Re: Anybody using the "top-down" solver?

[Oleg Grenrus]

I doubt this list has good coverage. You probably should try haskell-cafe?

Another way to put this question:

  Is anybody is still using GHC 6.x?

Cheers,
Oleg

> On 09 Nov 2015, at 06:29, Bardur Arantsson  wrote:
> 
> Hi all,
> 
> Just to get input from as many people as possible: I was pondering a
> plan for modularizing the solver[1] and wanted to reach as many people
> as possible with my question:
> 
>   Is anybody is still using the top-down solver?
> 
> Please respond to this list if you are, especially if you're doing so
> because there's no other way to get the modular solver to do what you
> want. (Obviously, I'm not promising to fix any problems you may have
> with the modular solver, but it would be valuable information since it
> could affect the decision of whether we have to keep the top-down solver
> around.)
> 
> Regards,
> 
> --
> [1] https://github.com/haskell/cabal/pull/2768#issuecomment-154917165
> 
> ___
> cabal-devel mailing list
> cabal-devel@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel