Re: set-root -> init

"W. Trevor King" <wking <at> drexel.edu> writes:

> On Fri, 12 Jun 2009 17:03:02 +0200, martin f krafft wrote:
> > Generally, I don't like set-root, I think that should be called
> > init.
> 
> I agree. Taking a look at test_usage.sh the setup command for all
> supported VCSs that have a single setup command (i.e. not Arch) is
> "init". This would be a pretty painless fix, but I thought I'd get a
> second opinion before changing the interface in my repo... Chris?

I would like ‘init’ to be a command that acknowledges there are
potentially a number of different things that need to be set up.
Currently, the only thing we need to set up (IIUC) is the project root,
but other things would certainly fit under the ‘init’ banner.

How about this UI:

    be init
    be init --root ROOTDIR

such that ROOTDIR defaults to ‘.’ if the ‘--root’ option is not
specified.

--

-- 
 \       “Everyone is entitled to their own opinions, but they are not |
  `\            entitled to their own facts.” —US Senator Pat Moynihan |
_o__)                                                                  |
Ben Finney

Re: Darcs support

Hi Trevor,

   > I've added support for the darcs patch-management system.

I get a test failure here, on a Fedora Rawhide machine.

======================================================================
ERROR: Should match file contents as committed to specified revision.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/www/html/bzr.bugseverywhere.org/be/libbe/rcs.py", line 808, in test_revision_file_contents_as_committed
    dup_repo_path = self.rcs.duplicate_repo(revision)
  File "/var/www/html/bzr.bugseverywhere.org/be/libbe/rcs.py", line 354, in duplicate_repo
    revision=revision)
  File "/var/www/html/bzr.bugseverywhere.org/be/libbe/darcs.py", line 135, in _rcs_duplicate_repo
    "--to-patch", revision, directory)
  File "/var/www/html/bzr.bugseverywhere.org/be/libbe/rcs.py", line 416, in _u_invoke_client
    return self._u_invoke(cl_args, stdin=stdin,expect=expect,cwd=directory)
  File "/var/www/html/bzr.bugseverywhere.org/be/libbe/rcs.py", line 408, in _u_invoke
    raise CommandError(strerror, status)
CommandError: Command failed (2): put
while executing ['darcs', 'put', '--no-pristine-tree', '--to-patch', 'Commit current status', '/tmp/BErcsvwvpTy/duplicate']

darcs failed:  unrecognized option `--no-pristine-tree'

pullcord:cjb~ % darcs --version                                                
2.2.1 (release)

I don't know anything about darcs, but from the 2.2.0 release notes:

Re: Darcs support

On Wed, Jul 01, 2009 at 09:34:04PM -0400, Chris Ball wrote:
>    > I've added support for the darcs patch-management system.
> 
> I get a test failure here, on a Fedora Rawhide machine.

I'm running
  $ darcs --version
  1.0.9 (release)
but it looks like upstream is up to 2.2.0.

Hmm.  I'm not even sure what --no-pristine-tree is supposed to do:

      --plain-pristine-tree  Use a plain pristine tree [DEFAULT]
      --no-pristine-tree     Use no pristine tree

Let's just remove that option...

--

-- 
This email may be signed or encrypted with GPG (http://www.gnupg.org).
The GPG signature (if present) will be attached as 'signature.asc'.
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt

_______________________________________________
Be-devel mailing list
Be-devel <at> bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel

Re: Re: set-root -> init

On Wed, Jul 01, 2009 at 11:31:51AM +1000, Ben Finney wrote:
> I would like "init" to be a command that acknowledges there are
> potentially a number of different things that need to be set up.
> Currently, the only thing we need to set up (IIUC) is the project root,
> but other things would certainly fit under the "init" banner.
> 
> How about this UI:
> 
>     be init
>     be init --root ROOTDIR

I like it.  In my branch now.

--

-- 
This email may be signed or encrypted with GPG (http://www.gnupg.org).
The GPG signature (if present) will be attached as 'signature.asc'.
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt

_______________________________________________
Be-devel mailing list
Be-devel <at> bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel

Some question about the development of be

Hello to everyone

As i said in a previous mail, I am working on a "html" command for be. 
The goal is to be able to do something like "be html /web/page" to have in the 
/web/page directory some static html pages that basically are the dump of the 
be repository, much like ditz have
This will enable a simple and fast publish of the bus list and details on the 
web, at least in read only mode.

So I'd like to ask some question:
1) is it ok to develop this command ? I know that this is not a fully featured 
web interface, but I am sure that it can be usefull.

I am open to suggestion about it of course.

2) I see that every command is implemented with a python file in the becommand 
dir. For a better code, I'd like to split the command implementation into two 
files: a file that contain the actual code and a second  file that have the html 
related part, any problem with this ? I don't like to have the html part and 
the code part in one big and unreadable file.

I'd like to hear other opinion about this.

Thanks for now
bye
Gianluca

Re: Some question about the development of be

Gianluca Montecchi <gian <at> grys.it> writes:

> 1) is it ok to develop this command ? I know that this is not a fully
> featured web interface, but I am sure that it can be usefull.

Yes, definitely. I can see it being a very easy way to put one's bug
database online for browsing.

> I am open to suggestion about it of course.

Instead of a separate command for each output format, could we have a
single “produce a static report of the bug database” command, and
specify output format as an option?

How about:

    be report
    be report --format ascii
    be report --format rst
    be report --format html

Where the ‘--format’ option has a default of, e.g., “ascii”.

This would mean that you are implementing the ‘html’ format of this
putative command.

> 2) I see that every command is implemented with a python file in the
> becommand dir. For a better code, I'd like to split the command
> implementation into two files: a file that contain the actual code and
> a second file that have the html related part, any problem with this ?

Re: Some question about the development of be

Hi Gianluca,

   > As i said in a previous mail, I am working on a "html" command
   > for be.  The goal is to be able to do something like "be html
   > /web/page" to have in the /web/page directory some static html
   > pages that basically are the dump of the be repository, much like
   > ditz have. This will enable a simple and fast publish of the bus
   > list and details on the web, at least in read only mode.

It might be a good idea for "be html" to use the CherryPy web interface
that Steve is working on.  The command could start up the CherryPy app
and scrape all of the available pages to get a stand-alone dump; this
would avoid having to keep two (okay, more than two at this point)
separate sets of HTML templates in the source tree.  What do you think?

   > 2) I see that every command is implemented with a python file in
   > the becommand dir. For a better code, I'd like to split the
   > command implementation into two files: a file that contain the
   > actual code and a second file that have the html related part,
   > any problem with this ? I don't like to have the html part and
   > the code part in one big and unreadable file.

I agree that becommands/*.py commands should not contain any HTML
layout code.  Putting it somewhere else instead sounds fine.

Thanks!

- Chris.
--

-- 
Chris Ball   <cjb <at> laptop.org>

Re: Some question about the development of be

Speaking of that interface, I changed up the look and feel a bit last  
weekend.  It's still at http://bitbucket.org/sjl/cherryflavoredbugseverywhere/ 
  -- if anyone has any feedback (on any aspect of it) I'd appreciate it.

--
Steve

On Jul 3, 2009, at 8:31 PM, Chris Ball wrote:

> Hi Gianluca,
>
>> As i said in a previous mail, I am working on a "html" command
>> for be.  The goal is to be able to do something like "be html
>> /web/page" to have in the /web/page directory some static html
>> pages that basically are the dump of the be repository, much like
>> ditz have. This will enable a simple and fast publish of the bus
>> list and details on the web, at least in read only mode.
>
> It might be a good idea for "be html" to use the CherryPy web  
> interface
> that Steve is working on.  The command could start up the CherryPy app
> and scrape all of the available pages to get a stand-alone dump; this
> would avoid having to keep two (okay, more than two at this point)
> separate sets of HTML templates in the source tree.  What do you  
> think?
>
>> 2) I see that every command is implemented with a python file in
>> the becommand dir. For a better code, I'd like to split the
>> command implementation into two files: a file that contain the
>> actual code and a second file that have the html related part,

Re: Some question about the development of be

Hi,

   > http://bitbucket.org/sjl/cherryflavoredbugseverywhere/

Cool!  I've set up a copy here:

   http://bugsweb.bugseverywhere.org/

(Since we don't have any open bugs lately, click "Closed" at the top,
or create some, but don't expect them to persist if you do.)

   > anyone has any feedback (on any aspect of it) I'd appreciate it.

I'm pretty enthusiastic about merging this and then working on it
further.

Thanks,

- Chris.
--

-- 
Chris Ball   <cjb <at> laptop.org>

Re: Re: Some question about the development of be

On Sat, Jul 04, 2009 at 10:19:35AM +1000, Ben Finney wrote:
> Instead of a separate command for each output format, could we have a
> single "produce a static report of the bug database" command, and
> specify output format as an option?
> 
> How about:
> 
>     be report
>     be report --format ascii
>     be report --format rst
>     be report --format html

Do people like this architecture better than my be-xml-to-mbox
approach?  I think the tradeoff is easy output format implementation
vs cluttered core codebase.  Should we use both, depending on how
useful people think the output format will be?

--

-- 
This email may be signed or encrypted with GPG (http://www.gnupg.org).
The GPG signature (if present) will be attached as 'signature.asc'.
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt

_______________________________________________
Be-devel mailing list
Be-devel <at> bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel