Notmuch BoF session at Debconf 14, portland
After some *cough* confusion, the notmuch BoF will be at 1530 on Monday August 25 in SMSU Room 238 of Portland State University. I haven't thought about a long agenda, but I could go quickly through my standard 15ish minute talk (which many of you might have seen on video from last year), and then open the floor to questions / demos / hacking. d
[PATCH v3 04/13] lib: Database version 3: Introduce fine-grained "features"
Quoth David Bremner on Aug 23 at 8:58 pm:
> Austin Clements writes:
>
> >>> @@ -1048,7 +1164,8 @@ notmuch_database_get_version (notmuch_database_t
> >>> *notmuch)
> >>> notmuch_bool_t
> >>> notmuch_database_needs_upgrade (notmuch_database_t *notmuch)
> >>> {
> >>> -return notmuch->needs_upgrade;
> >>> +return notmuch->mode == NOTMUCH_DATABASE_MODE_READ_WRITE &&
> >>> + (NOTMUCH_FEATURES_CURRENT & ~notmuch->features);
> >>> }
> >>
> >> Maybe I'm not thinking hard enough here, but how does this deal with a
> >> feature that is needed to open a database in read only mode? Maybe it
> >> needs a comment for people not as clever as Austin ;).
> >
> > I'm not quite sure what you mean. notmuch_database_needs_upgrade
> > returns false for read-only databases because you can't upgrade a
> > read-only database. This was true before this patch, too, though it was
> > less obvious. (Maybe that's not what you're asking?)
>
> Yes, that's what I was asking. I guess it's orthogonal to your patch
> series, but the logic of returning FALSE for read only databases is not
> very intuitive to me (in the sense that "needs upgrade" is not the
> opposite of "can't be upgraded". Your new comment later in the series
> is better, but it would IMHO be even better if you mentioned the read
> only case.
That's a good point. Ideally this should be
"notmuch_database_can_upgrade" or something, which I think would
capture exactly what it means after this series. However, I don't
think it's worth breaking API compatibility given that this is already
how callers use this function (even though that violates the current
library spec).
So, how's this for a more updated doc comment on needs_upgrade?
/**
* Can the database be upgraded to a newer database version?
*
* If this function returns TRUE, then the caller may call
* notmuch_database_upgrade to upgrade the database. If the caller
* does not upgrade an out-of-date database, then some functions may
* fail with NOTMUCH_STATUS_UPGRADE_REQUIRED. This always returns
* FALSE for a read-only database because there's no way to upgrade a
* read-only database.
*/
[PATCH v3 03/13] new: Don't report version after upgrade
On Sun, 24 Aug 2014, Austin Clements wrote: > Quoth Jani Nikula on Aug 23 at 6:39 pm: >> On Fri, 01 Aug 2014, Austin Clements wrote: >> > The version number has always been pretty meaningless to the user and >> > it's about to become even more meaningless with the introduction of >> > "features". Hopefully, the database will remain on version 3 for some >> > time to come; however, the introduction of new features over time in >> > version 3 will necessitate upgrades within version 3. It would be >> > confusing if we always tell the user they've been "upgraded to version >> > 3". If the user wants to know what's new, they should read the news. >> >> I think this is good for now. >> >> What do you think about adding notmuch_database_get_features(), and >> printing that? > > Mark had a similar comment, so here's my reply: > id:20140727162426.GF13893 at mit.edu > > I'm happy with adding more transparency around this, though I'd prefer > to do it as follow-up to avoid expanding this series and because I'm > pretty sure adding something like notmuch_database_get_features > wouldn't require any non-trivial changes to the stuff in this series. Agreed. BR, Jani.
[PATCH v3] nmbug: Translate to Python
"W. Trevor King" writes: > >> > +__version__ = '0.2' >> >> Do we need/want a version distinct from that of notmuch? > > nmbug is very loosely bound to the notmuch core. To me it feels like > a separate project that happens to share the same version control > repository. I'm happy to synchronize versions, but then we have to > remember to bump the nmbug version for each notmuch release. Unless/until we split nmbug from notmuch I'd rather keep the versions the same to avoid confusion. I guess the "right way" (TM) would be share the hackery used in doc/conf.py to parse the version file and use it from python. >> as a non-native speaker of python, I find this a bit hard to read. >> How about adding some parens to make the multiple return more clear, >> so >> >> (status, tree, stderr) = _git( > > That's legal, but I rarely see the parenthesized version in the wild. > For examples showing the unparenthesized version, see [2,3]. > Parentheses are optional for Python tuples [4], so you'd only want > them if ?=? had a higher precedence than ?,?. That's my argument for > the unparenthesized version, but feel free to overrule me ;). I'd rather go with readability (which I admit is subjective) then try to minimize parens. We're lisp programmers, after all ;).
[PATCH v3] nmbug: Translate to Python
"W. Trevor King" writes:
> On Tue, Aug 05, 2014 at 10:24:10PM -0300, David Bremner wrote:
>> I have a local commit that deletes a couple tags; when I attempt to
>> merge I get complaints about local changes to files.
>>
>> error: Your local changes to the following files would be overwritten by
>> merge:
>> tags/1406859003-11561-2-git-send-email-amdragon at mit.edu/needs-review
>> tags/1406859003-11561-3-git-send-email-amdragon at mit.edu/needs-review
>> Please, commit your changes or stash them before you can merge.
>> ?
>> Calling the perl version of nmbug successfully creates a little
>> diamond merge
>
> The Perl version has:
>
> git ( { GIT_WORK_TREE => $tempwork }, 'checkout', '-f', 'HEAD');
> git ( { GIT_WORK_TREE => $tempwork }, 'merge', $commit);
>
> But the Python version only has:
>
> _git(
> args=['merge', reference],
> additional_env={'GIT_WORK_TREE': workdir},
> wait=True)
>
> I suppose we need the checkout to populate the working directory, but
> I'm not sure we want to force the checkout. Do we expect to have
> unmerged entries in the index?
I can't remember now why the checkout was forced, so as long as you can
test it, I guess try the unforced version first. I guess the merge will
fail if there are unmerged entries in the index, but maybe we can find
out why that happens and prevent it.
d
[PATCH v3] nmbug: Translate to Python
"W. Trevor King" writes: >> Traceback (most recent call last): >> File "/home/bremner/config/scripts/nmbug", line 766, in >> args.func(**kwargs) >> File "/home/bremner/config/scripts/nmbug", line 463, in push >> _git(args=args, wait=True) >> File "/home/bremner/config/scripts/nmbug", line 210, in _git >> return _spawn(args=args, **kwargs) >> File "/home/bremner/config/scripts/nmbug", line 193, in _spawn >> args=args, status=status, stdout=stdout, stderr=stderr) >> __main__.SubprocessError: ['git', '--git-dir', '/home/bremner/.nmbug', >> 'push'] exited with 1 > > I can drop the backtrace and just print the SubprocessError, and just > show the traceback if the logging is set to ?debug?. If that sounds > reasonable, I'll to it in v4. Yeah, I'd leave the hint lines for now.
Re: [PATCH v3 03/13] new: Don't report version after upgrade
On Sun, 24 Aug 2014, Austin Clements amdra...@mit.edu wrote: Quoth Jani Nikula on Aug 23 at 6:39 pm: On Fri, 01 Aug 2014, Austin Clements amdra...@mit.edu wrote: The version number has always been pretty meaningless to the user and it's about to become even more meaningless with the introduction of features. Hopefully, the database will remain on version 3 for some time to come; however, the introduction of new features over time in version 3 will necessitate upgrades within version 3. It would be confusing if we always tell the user they've been upgraded to version 3. If the user wants to know what's new, they should read the news. I think this is good for now. What do you think about adding notmuch_database_get_features(), and printing that? Mark had a similar comment, so here's my reply: id:20140727162426.gf13...@mit.edu I'm happy with adding more transparency around this, though I'd prefer to do it as follow-up to avoid expanding this series and because I'm pretty sure adding something like notmuch_database_get_features wouldn't require any non-trivial changes to the stuff in this series. Agreed. BR, Jani. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3] nmbug: Translate to Python
W. Trevor King wk...@tremily.us writes: Traceback (most recent call last): File /home/bremner/config/scripts/nmbug, line 766, in module args.func(**kwargs) File /home/bremner/config/scripts/nmbug, line 463, in push _git(args=args, wait=True) File /home/bremner/config/scripts/nmbug, line 210, in _git return _spawn(args=args, **kwargs) File /home/bremner/config/scripts/nmbug, line 193, in _spawn args=args, status=status, stdout=stdout, stderr=stderr) __main__.SubprocessError: ['git', '--git-dir', '/home/bremner/.nmbug', 'push'] exited with 1 I can drop the backtrace and just print the SubprocessError, and just show the traceback if the logging is set to ‘debug’. If that sounds reasonable, I'll to it in v4. Yeah, I'd leave the hint lines for now. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3] nmbug: Translate to Python
W. Trevor King wk...@tremily.us writes:
On Tue, Aug 05, 2014 at 10:24:10PM -0300, David Bremner wrote:
I have a local commit that deletes a couple tags; when I attempt to
merge I get complaints about local changes to files.
error: Your local changes to the following files would be overwritten by
merge:
tags/1406859003-11561-2-git-send-email-amdra...@mit.edu/needs-review
tags/1406859003-11561-3-git-send-email-amdra...@mit.edu/needs-review
Please, commit your changes or stash them before you can merge.
…
Calling the perl version of nmbug successfully creates a little
diamond merge
The Perl version has:
git ( { GIT_WORK_TREE = $tempwork }, 'checkout', '-f', 'HEAD');
git ( { GIT_WORK_TREE = $tempwork }, 'merge', $commit);
But the Python version only has:
_git(
args=['merge', reference],
additional_env={'GIT_WORK_TREE': workdir},
wait=True)
I suppose we need the checkout to populate the working directory, but
I'm not sure we want to force the checkout. Do we expect to have
unmerged entries in the index?
I can't remember now why the checkout was forced, so as long as you can
test it, I guess try the unforced version first. I guess the merge will
fail if there are unmerged entries in the index, but maybe we can find
out why that happens and prevent it.
d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3] nmbug: Translate to Python
W. Trevor King wk...@tremily.us writes: +__version__ = '0.2' Do we need/want a version distinct from that of notmuch? nmbug is very loosely bound to the notmuch core. To me it feels like a separate project that happens to share the same version control repository. I'm happy to synchronize versions, but then we have to remember to bump the nmbug version for each notmuch release. Unless/until we split nmbug from notmuch I'd rather keep the versions the same to avoid confusion. I guess the right way (TM) would be share the hackery used in doc/conf.py to parse the version file and use it from python. as a non-native speaker of python, I find this a bit hard to read. How about adding some parens to make the multiple return more clear, so (status, tree, stderr) = _git( That's legal, but I rarely see the parenthesized version in the wild. For examples showing the unparenthesized version, see [2,3]. Parentheses are optional for Python tuples [4], so you'd only want them if ‘=’ had a higher precedence than ‘,’. That's my argument for the unparenthesized version, but feel free to overrule me ;). I'd rather go with readability (which I admit is subjective) then try to minimize parens. We're lisp programmers, after all ;). ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 04/13] lib: Database version 3: Introduce fine-grained features
Austin Clements amdra...@mit.edu writes:
Quoth David Bremner on Aug 23 at 8:58 pm:
Austin Clements amdra...@mit.edu writes:
@@ -1048,7 +1164,8 @@ notmuch_database_get_version (notmuch_database_t
*notmuch)
notmuch_bool_t
notmuch_database_needs_upgrade (notmuch_database_t *notmuch)
{
-return notmuch-needs_upgrade;
+return notmuch-mode == NOTMUCH_DATABASE_MODE_READ_WRITE
+(NOTMUCH_FEATURES_CURRENT ~notmuch-features);
}
Maybe I'm not thinking hard enough here, but how does this deal with a
feature that is needed to open a database in read only mode? Maybe it
needs a comment for people not as clever as Austin ;).
I'm not quite sure what you mean. notmuch_database_needs_upgrade
returns false for read-only databases because you can't upgrade a
read-only database. This was true before this patch, too, though it was
less obvious. (Maybe that's not what you're asking?)
Yes, that's what I was asking. I guess it's orthogonal to your patch
series, but the logic of returning FALSE for read only databases is not
very intuitive to me (in the sense that needs upgrade is not the
opposite of can't be upgraded. Your new comment later in the series
is better, but it would IMHO be even better if you mentioned the read
only case.
That's a good point. Ideally this should be
notmuch_database_can_upgrade or something, which I think would
capture exactly what it means after this series. However, I don't
think it's worth breaking API compatibility given that this is already
how callers use this function (even though that violates the current
library spec).
So, how's this for a more updated doc comment on needs_upgrade?
LGTM
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Notmuch BoF session at Debconf 14, portland
After some *cough* confusion, the notmuch BoF will be at 1530 on Monday August 25 in SMSU Room 238 of Portland State University. I haven't thought about a long agenda, but I could go quickly through my standard 15ish minute talk (which many of you might have seen on video from last year), and then open the floor to questions / demos / hacking. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
