Themes for 1.22

Thu Apr 24 12:41:52 UTC 2014

Having to share code via releases is indeed the problem with an internal
Hackage. I don't see that scaling well as an organization gets bigger. You
really need to be able to check out the organization's source repo and have
that contain a bunch of (non-released) packages and build them together.

On Thu, Apr 24, 2014 at 2:10 PM, Benjamin Edwards <edwards.benj at gmail.com>wrote:

> I will definitely look into that! Thank you. The one your that does force
> you down though is the path only developing against releases, and even
> those are light-weight internal patch releases to your own hackage it still
> means a longer compile-test cycle. Maybe if that's a problem it indicates
> that my package boundaries are too fine, but I find add-source to be
> invaluable, I would find it even nicer if it was a little bit more first
> class. If you look at how source dependencies are covered in VS when
> programming in .Net, that's somewhat how I would like to see it managed in
> cabal. It's trivial to have common assemblies in a source tree shared
> between projects.
>
> Ben
>
> On Thu Apr 24 2014 at 12:50:45, Erik Hesselink <hesselink at gmail.com>
> wrote:
>
>> You can handle this scenario pretty easily by setting up a private
>> hackage. Then add a second remote-repo to your cabal config, either
>> globally or in the sandbox. We do this, and it works pretty well.
>>
>> Regards,
>>
>> Erik
>>
>> On Thu, Apr 24, 2014 at 1:33 PM, Benjamin Edwards
>> <edwards.benj at gmail.com> wrote:
>> > Hi Johan,
>> >
>> > Not sure if this mail is a request for comments, but on the story for
>> large
>> > projects one thing that I would like to see is the ability to add
>> packages
>> > that aren't in hackage to the depends list. I agree that adding some
>> > scanning and auto add ability is definitely sorely needed, but this
>> > information goes into add-source-timestamps in the sandbox folder, and
>> if
>> > you blow away the sandbox, it's gone. Or you can try and version a file
>> that
>> > contains ever changing timestamps. Right now I have a shell script that
>> > maintains a list of added sources and I keep that versioned in the
>> project.
>> > It would be nice to have git dependencies in there as well, and then
>> > disallow a hackage upload for any cabal file with a non-hackage
>> dependency
>> > listed. I would be happy to contribute time to both design and
>> > implementation.
>> >
>> > Ben
>> >
>> > On Thu Apr 24 2014 at 10:53:59, Johan Tibell <johan.tibell at gmail.com>
>> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> While I'm sure we still have a bugfix release or two to make on the
>> 1.20
>> >> branch, I thought it'd be worth looking at what we want to accomplish
>> for
>> >> 1.22. Here are my thoughts on what we should focus on:
>> >>
>> >> ## A dependency solver that always works
>> >>
>> >> As Hackage has grown so have the requirements of the dependency solver.
>> >> There are three distinct problems I'm seeing now that we should tackle:
>> >>
>> >>  * Treat each sections (i.e. library, test suite, benchmark, and
>> >> executable) in the .cabal file separately for the purpose of dependency
>> >> resolution. Today all the sections' dependencies are merged and used
>> as the
>> >> constraints of the package as a whole. This is troublesome for all
>> packages
>> >> that are dependencies of QC, HUnit, test-framework, and criterion, as
>> >> there's a dependency cycle if you treat e.g. the containers package
>> and its
>> >> test suite as one unit.
>> >>
>> >>    The solution here is to treat each unit as a mini package for the
>> >> purpose of dependency resolution. This would also allow you to have
>> e.g.
>> >> several executables with conflicting dependencies.
>> >>
>> >>  * Improve performance. Some packages (e.g. yesod) can take over 10
>> >> seconds to run over. This problem will get worse as Hackage grows and
>> we
>> >> build bigger applications on top of it, so we need to tackle this now
>> before
>> >> it becomes a real problem.
>> >>
>> >>  * Fix Hackage package blacklisting. Users can blacklist packages on
>> >> Hackage e.g. if they know them to be broken. However, this doesn't
>> really
>> >> work as the Hackage blacklist translates to a soft preference in the
>> >> dependency solver and is thus often ignored. See
>> >> https://github.com/haskell/cabal/issues/1792 for the gory details.
>> >>
>> >> ## Do the right thing automatically
>> >>
>> >> This is a carry-over from the 1.20 goals, as we didn't make much
>> progress
>> >> here.
>> >>
>> >> The focus here should be on avoiding manual steps the cabal could do
>> >> for the user.
>> >>
>> >>  * Automatically install dependencies when needed. When `cabal build`
>> >> would fail due to a missing dependency, just install this dependency
>> >> instead of bugging the user to do it. This will probably have to be
>> >> limited to sandboxes where we can't break the user's system
>> >>
>> >>  * GHCi support could be improved by rebinding :reload to rerun e.g.
>> >> preprocessors automatically. This would enable the users to develop
>> >> completely from within ghci (i.e. faster edit-save-type-error cycle).
>> >> We have most of what we need here (i.e. GHC macro support) but someone
>> >> needs to make the final change to generate a .ghci file to pass in the
>> >> ghci invocation.
>> >>
>> >> ## Faster builds
>> >>
>> >> I think we're almost done here. There's really only one remaining
>> thing to
>> >> do:
>> >>
>> >>  * Build components and different ways (e.g. profiling) in parallel.
>> >> We could build both profiling and non-profiling versions in parallel.
>> >> We could also build e.g. all test suites in parallel. The key
>> >> challenge here is to coordinate all parallel jobs so we don't spawn
>> >> too many.
>> >>
>> >> ## Support large projects
>> >>
>> >> This is also a carry-over from the 1.20 goals.
>> >>
>> >> We still don't have a good story for large projects. Sandboxes are too
>> >> annoying to use if there are 100 add-source deps. We need more
>> automation
>> >> and more opinionated defaults (e.g. scan the sub-directories from in
>> which
>> >> cabal was run to find source packages.)
>> >>
>> >> What we need most of all here is a design. Perhaps we could try to get
>> >> together at some Hackathon/ICFP and discuss.
>> >>
>> >> ## Issue tracker spring cleaning and test suite improvements
>> >>
>> >> The issue tracker is out-of-hand. It's too unwieldy to use for planning
>> >> our work and get an overview of the most important issues. We should
>> try to
>> >> close down bugs that haven't had updates in years with extreme
>> prejudice. If
>> >> the issue is important it will pop up again.
>> >>
>> >> We're also severely lacking in the testing department. There are two
>> >> problems:
>> >>
>> >>  * There aren't enough tests: the cabal user facing surface is quite
>> >> larger (lots of features and flags) and many of them are not tested at
>> all,
>> >> which will lead to regressions as we keep fixing bugs and adding
>> features.
>> >>
>> >>  * The tests take too long to run: we have too many end-to-end style
>> tests
>> >> (i.e. build a whole package) and not enough unit style tests. We need
>> to add
>> >> more of the latter kind.
>> >>
>> >> Cheers,
>> >>   Johan
>> >>
>> >> _______________________________________________
>> >> cabal-devel mailing list
>> >> cabal-devel at haskell.org
>> >> http://www.haskell.org/mailman/listinfo/cabal-devel
>> >
>> >
>> > _______________________________________________
>> > cabal-devel mailing list
>> > cabal-devel at haskell.org
>> > http://www.haskell.org/mailman/listinfo/cabal-devel
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140424/7f06a1a9/attachment-0001.html>