PGXN Utils 0.1.4dev

[Dickson S. Guedes]

Hi all!

Before release PGXN Utils 0.1.4 I'd like listen for some revision in
the README [1], because I cannot feel that it is clear for the new
features of pgxn-utils.

I appreciate your suggestion to improvements and text correction.
Please, let me know!

Thanks!

[1] https://github.com/guedes/pgxn-utils/blob/master/README.md
--
Dickson S. Guedes
e-mail/gtalk: gue...@guedesof.net  - skype: guediz
http://github.com/guedes - http://www.postgresql.org.br

[David E. Wheeler]

On Nov 20, 2011, at 6:42 PM, Dickson S. Guedes wrote:

> Before release PGXN Utils 0.1.4 I'd like listen for some revision in
> the README [1], because I cannot feel that it is clear for the new
> features of pgxn-utils.
>
> I appreciate your suggestion to improvements and text correction.
> Please, let me know!

Finally got around to this and sent you a pull request. From the comments there:

In most of the example commands, you include the name of the extension. Is it not the case that if you run the tasks in the extension root directory, you don't have to do that? That is, it assumes the current directory? If so, I think that should be spelled-out, as well.

Also, I've noticed that when I do that, `pgxn-utils bundle` puts the zip file in the parent directory. Took me a few minutes to find it. I think it should just be created in the current directory, or else there should be a message saying where to find it. Furthermore, I think that `pgxn release` should know where to find it, too (which, if it was in the current directory, would be simple).

And finally, I suggest you move this file into `docs/pgxn-utils.md` or similar, add a `docfile` key to `provides:pgxn_utils` that points at it, and then make the `README.md` more generic. I'm thinking like [semver](http://api.pgxn.org/src/semver/semver-0.2.3/), where the README has installation and license information, and the `doc/semver.mmd` file is the usage documentation. Thoughts?

Thanks agin for this, looks great!

Oh, one more thing: How about mentioning the integration with the `pgxn` command-line client?

Best,

David

[Dickson dos Santos Guedes]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Em 27-11-2011 21:38, David E. Wheeler escreveu:
> On Nov 20, 2011, at 6:42 PM, Dickson S. Guedes wrote:
>> Before release PGXN Utils 0.1.4 I'd like listen for some revision in
>> the README [1], because I cannot feel that it is clear for the new
>> features of pgxn-utils.
>>
>> I appreciate your suggestion to improvements and text correction.
>> Please, let me know!
>
> Finally got around to this and sent you a pull request. From the comments there:

Thanks David!

> In most of the example commands, you include the name of the extension. Is it not the case that if you run the tasks in the extension root directory, you don't have to do that? That is, it assumes the current directory? If so, I think that should be spelled-out, as well.

+1.

> Also, I've noticed that when I do that, `pgxn-utils bundle` puts the zip file in the parent directory. Took me a few minutes to find it. I think it should just be created in the current directory, or else there should be a message saying where to find it. Furthermore, I think that `pgxn release` should know where to find it, too (which, if it was in the current directory, would be simple).

There is a message. How is the `pgxn-utils bundle` output when you are
inside some extension dir?

> And finally, I suggest you move this file into `docs/pgxn-utils.md` or similar, add a `docfile` key to `provides:pgxn_utils` that points at it, and then make the `README.md` more generic. I'm thinking like [semver](http://api.pgxn.org/src/semver/semver-0.2.3/), where the README has installation and license information, and the `doc/semver.mmd` file is the usage documentation. Thoughts?

+1.

> Thanks agin for this, looks great!

Thanks for your suggestions!

> Oh, one more thing: How about mentioning the integration with the `pgxn` command-line client?

I'm working on that, because "gem install pgxn_utils" doesn't create
symlinks, then I should create a new task that will create them.

[]s
- --
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://guedesoft.net - http://www.postgresql.org.br
http://github.net/guedes - twitter: @guediz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJO06aLAAoJEBa5zL7BI5C7Z3cH/2tXvn/GPndTQZWwYitRU1eJ
jO+Ojpkwe08Bn8IX42cTmvP8QHCaVBDmKuQZzxXo3O2j5HPHaIJSJrxmxWuwFZfc
z275f/jQc2jRxwNJZenIOoKU8iW5jU5qwHVmyvcSCnAsqhmnEXvoFXZlOaAqRhHu
9+iuZlYvItWgXJHhaj4w2GGPl8eDYTd/d+VfJ58ZPCA9IZ2xlBXs6iixguSrRN2f
W3+J2KeSTu/bE/YZOEJGw3K/PjGxIg0+vCSvrUKMaIaLt2psJXkUysR6sqoW9hks
kxKplsZnnN5+RRTEQQNsWLxj8CMTZ8j4bn4lY5nZdaF6hUyxuGVAOaxul4hRI1A=
=pkTp
-----END PGP SIGNATURE-----

[Daniele Varrazzo]

On Mon, Nov 28, 2011 at 3:19 PM, Dickson dos Santos Guedes
<gue...@guedesoft.net> wrote:
> Em 27-11-2011 21:38, David E. Wheeler escreveu:

>> Oh, one more thing: How about mentioning the integration with the `pgxn` command-line client?
>
> I'm working on that, because "gem install pgxn_utils" doesn't create
> symlinks, then I should create a new task that will create them.

Hi Guedes,

You have commands:

pgxn-utils bundle [extension_name] # Bundles the extension in a zip file
pgxn-utils change [extension_name] # Changes META's attributes in
current extension
pgxn-utils help [TASK] # Describe available tasks or
one specific task
pgxn-utils release filename # Release an extension to PGXN
pgxn-utils skeleton extension_name # Creates an extension skeleton
in current directory

How would you like to have them invoked by the client's dispatcher?
"pgxn utils bundle" or "pgxn bundle"? I think the second option would
be better, it would look "more integrated". bundle, change, release,
and skeleton are not names used by the client so you could have them
as client commands without conflicts.

Also, do your commands support a --help option? I'm asking as David
asked to convert pgxn help CMD into pgxn CMD --help so that an help
request could be forwarded by the client dispatcher to the external
command (https://github.com/dvarrazzo/pgxnclient/issues/7). This way
the fact you have an "help" command too wouldn't be a conflict.

About symlinks creation at install time, I believe you already know
everything. But just in case, the tasks for having it could be, in
pseudo-bash:

DIR = $(pgxn help --libexec)
sudo mkdir -p "$DIR"
for CMD in bundle change release skeleton; do
sudo ln -sf /path/to/pgxnutils-bridge "$DIR/pgxn-$CMD";
done

where "pgxnutils-bridge" is an hypothetical script taking its name
from argv[0] (e.g. pgxn-bundle) and executing "pgxn-utils bundle $*".
The "bridge" could be the "pgxn-utils" script itself, why not, that
would pay attention to the way it is called and interpret
"pgxn-bundle" as "pgxn-utils bundle".

This is just my idea, you may have better ones ;)

-- Daniele

[Dickson dos Santos Guedes]

Em 28-11-2011 14:08, Daniele Varrazzo escreveu:
> How would you like to have them invoked by the client's dispatcher?
> "pgxn utils bundle" or "pgxn bundle"?

The first one already works, I'm working in the second one, that is more
concise.

> I think the second option would
> be better, it would look "more integrated". bundle, change, release,
> and skeleton are not names used by the client so you could have them
> as client commands without conflicts.

Yes. +1.

> Also, do your commands support a --help option?

Not, yet.

> I'm asking as David
> asked to convert pgxn help CMD into pgxn CMD --help so that an help
> request could be forwarded by the client dispatcher to the external
> command (https://github.com/dvarrazzo/pgxnclient/issues/7). This way
> the fact you have an "help" command too wouldn't be a conflict.

I'll introduce a --help. Thanks.

> About symlinks creation at install time, I believe you already know
> everything. But just in case, the tasks for having it could be, in
> pseudo-bash:
>
> DIR = $(pgxn help --libexec)
> sudo mkdir -p "$DIR"
> for CMD in bundle change release skeleton; do
> sudo ln -sf /path/to/pgxnutils-bridge "$DIR/pgxn-$CMD";
> done

The problem now is with RubyGems. It doesn't allow you to create
something like a POSTINSTALL script. I'll introduce a step to create
them and add it to Makefile. So when we install pgxn-utils using
pgxnclient it works automagically.

Just a last point, in my tests I put the "bridges" in $PATH instead
"libexec", and it works. Is that a expected behavior?

Thanks Daniele!

[Daniele Varrazzo]

On Mon, Nov 28, 2011 at 4:46 PM, Dickson dos Santos Guedes
<gue...@guedesoft.net> wrote:

> The problem now is with RubyGems. It doesn't allow you to create
> something like a POSTINSTALL script. I'll introduce a step to create
> them and add it to Makefile. So when we install pgxn-utils using
> pgxnclient it works automagically.

Sounds familiar... It's one of the reasons why I'm not creating the
libexec dir in first place: the python package manager doesn't allow
that step (but the main reason is that I don't want to unconditionally
create a directory that may be not in line with distributions
policies: I'm expecting rpm/deb/whatever to patch the client putting
libexec wherever they like and to create the dir via their own package
manager).

> Just a last point, in my tests I put the "bridges" in $PATH instead
> "libexec", and it works. Is that a expected behavior?

Yes, it is. libexec is added in front of the PATH and commands are
looked for along the entire list.

-- Daniele

[David E. Wheeler]

On Nov 28, 2011, at 8:08 AM, Daniele Varrazzo wrote:

> pgxn-utils skeleton extension_name # Creates an extension skeleton
> in current directory

Forgot to mention that I was wondering if "scaffold" might be a better name than "skeleton." Thoughts?

David

[Daniele Varrazzo]

I think "skeleton" is a more common name for the concept.

-- Daniele

[David E. Wheeler]

On Nov 28, 2011, at 9:41 AM, Daniele Varrazzo wrote:

>> Forgot to mention that I was wondering if "scaffold" might be a better name than "skeleton." Thoughts?
>
> I think "skeleton" is a more common name for the concept.

Okay, fine with me.

David

[Dickson dos Santos Guedes]

+1

[David E. Wheeler]

On Nov 28, 2011, at 7:19 AM, Dickson dos Santos Guedes wrote:

> There is a message. How is the `pgxn-utils bundle` output when you are
> inside some extension dir?

Ah, so there is:

master > pgxn_utils bundle
run make distclean from "."
create /Users/david/dev/github/pgtap-0.90.0.zip

So it's in `../`. I still expect it to be in `.`. The nice thing about that is that I could then potentially type `pgxn_utils release` with no named file, and it would see it there already, with the proper version number from the META.json file.

> I'm working on that, because "gem install pgxn_utils" doesn't create
> symlinks, then I should create a new task that will create them.

Really? No way to hook into the gem stuff to create additional files or symlinks or anything? Bummer.

Best,

David

[Dickson S. Guedes]

Em 03-12-2011 17:59, David E. Wheeler escreveu:
> On Nov 28, 2011, at 7:19 AM, Dickson dos Santos Guedes wrote:
>
>> There is a message. How is the `pgxn-utils bundle` output when you are
>> inside some extension dir?
>
> Ah, so there is:
>
> master > pgxn_utils bundle
> run make distclean from "."
> create /Users/david/dev/github/pgtap-0.90.0.zip
>
> So it's in `../`. I still expect it to be in `.`. The nice thing about that is that I could then potentially type `pgxn_utils release` with no named file, and it would see it there already, with the proper version number from the META.json file.

I'm with you.

I'm in vacation for 15 days, and while I'm in the beach, relaxing I'm
thinking about this and other improvements.

What about a 'pkg' in '.' ? Then, when you do a `pgxn-utils release` it
looks for a file inside it with the expected version.

I'll work on that. Thanks!

>> I'm working on that, because "gem install pgxn_utils" doesn't create
>> symlinks, then I should create a new task that will create them.
>
> Really? No way to hook into the gem stuff to create additional files or symlinks or anything? Bummer.

My problem is the same as Daniele have with `.eggs`. I'll try to cover
this "deficit" in many places: 1) Makefile, 2) hardcopys in `bin` dir,
3) a task to create symlinks manually.

Thanks!

[David E. Wheeler]

On Dec 5, 2011, at 7:37 AM, Dickson S. Guedes wrote:

> I'm with you.
>
> I'm in vacation for 15 days, and while I'm in the beach, relaxing I'm
> thinking about this and other improvements.

I’m jealous. It’s bloody cold here, -1c this morning. Sure wish I was on a beach. Not sure I’d be thinking about this, though.

> What about a 'pkg' in '.' ?

I don’t understand the question, sorry.

> Then, when you do a `pgxn-utils release` it
> looks for a file inside it with the expected version.

Yes, that would be ideal, IMHO.

> I'll work on that. Thanks!

Guediz++

>> Really? No way to hook into the gem stuff to create additional files or symlinks or anything? Bummer.
>
> My problem is the same as Daniele have with `.eggs`. I'll try to cover
> this "deficit" in many places: 1) Makefile, 2) hardcopys in `bin` dir,
> 3) a task to create symlinks manually.

Cool, hope it works out.

Best,

David

[Daniele Varrazzo]

On Mon, Dec 5, 2011 at 3:37 PM, Dickson S. Guedes <gue...@guedesoft.net> wrote:

> My problem is the same as Daniele have with `.eggs`. I'll try to cover
> this "deficit" in many places: 1) Makefile, 2) hardcopys in `bin` dir,
> 3) a task to create symlinks manually.

Yup, I'm afraid so. I kinda see that installing stuff around is really
a work for a distro package manager, but it really gets in the way...

If I were in you, I'd go for option 3: have some "sudo pgxn-utils
register-client" create the $(pgxn help --libexec) directory and the
symlinks you need.

-- Daniele