Upcoming changes...

[Martin Blais]

The Beancount documentation is now complete.

I had to work through a *lot* of procrastination to get there :-)

I'd like to do a few things before releasing a 2.0 version and move to semantic versioning thereafter.

These may affect you, especially if you're packaging an installation.

Please let me know ASAP if any of these is going to have any material impact on what you do (I don't think but I prefer to send a heads-up).

- I'd like to move "src/python/beancount/" to just a "beancount/" subdirectory under the root, to follow well-worn conventions in the Python community. Let me know if this makes sense to you. My source code was located where it is now from an old convention I've had for private repositories which support multiple programming languages and I realize it is somewhat unusual. This project is popular enough at this point (we have 122 people on the list) I should try to make it conform to what most people expect from a Python package before the release. This also means the Emacs support file (beancount.el) will move somewhere else.

- The beancount.projects.returns code that computes investment returns was put out there a long time ago, but it had some remaining flaws that made it difficult to use and especially difficult if not impossible to debug. Because of this, I doubt anyone uses it (but I can't know for sure). A long time ago I began to rewrite it and fix those issues but that work fell by the wayside and now still lives in a branch ("returns2"), sitting there incomplete. I'd like to clean things up by removing the script and moving this rewrite to experiments/ until I have time to complete this, where it belongs. If you're using beancount.projects.returns and it works for you, please let me know right away (and I'll be really surprised).

- I'll move out codes that are used for development from beancount.* into tools/. This includes everything under src/python/beancount/docs, beancount.scripts.example, and beancount.scripts.tutorial. I don't think this should affect anyone. These don't belong in the main codebase, as they should not need to be invoked by users.

Other tasks that will be done before the release are:

- Complete small refactoring for conversions to cost basis and market value

- Fix issue #145

- Write some code to download and convert documentation from GDocs to markdown for inclusion in Dominik Aumayr's generated docs (http://aumayr.github.io/beancount-docs-static/).

[yegle]

Hi Martin,

While you are re-organizing your code, I was wondering if maybe you could start accepting PR on the official mirror (https://github.com/beancount/beancount/), or even move the project to Github? I'm not sure if this has been brought up in the past, but git is arguably more familiar to many peoples compare to mercurial.

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+unsubscribe@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhNrm7B5BEaSRhg-RVRVXN51jC9hSdjjovboix2Yr1d9fQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Yuchen Ying
http://about.me/yegle

[Martin Blais]

On Sun, Jan 8, 2017 at 10:54 PM, yegle <cny...@gmail.com> wrote:

Hi Martin,

While you are re-organizing your code, I was wondering if maybe you could start accepting PR on the official mirror (https://github.com/beancount/beancount/), or even move the project to Github? I'm not sure if this has been brought up in the past, but git is arguably more familiar to many peoples compare to mercurial.

I hear you. Probably not for a while though. I've had difficulties with git I haven't encountered with Mercurial (and I'm not saying this from just surface usage, I know it fairly well, its strengths and limitations and to discuss those issues would require talking about a lot of stuff most people don't care about. I used to support other devs' usage of git, encountered so many problems in comparison with hg, so it's much more than "I don't like it"). Mercurial has been much more robust over the years, and despite github's popularity, I have heard many times from people who work closely on scaling these things that they have a similar experience as mine. That being said, input taken, never say never... I can see github's popularity.

Note that I haven't handled tickets/PRs in a while, mainly because I'm focused on the boring parts of getting to a release, like finishing the docs. Once the release is done I want to spend a bit more time processing tickets and PRs and also some low-hanging fruit.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAFL5w3V2vLy2aA3NJB5btAUt8VwvuxdPnf%2BXrgDsD_vi19L9Dw%40mail.gmail.com.