Re: throw away module namespace

2014-12-16 Thread Smylers
Neil Bowers writes:

 You could put the modules in Acme::, which is another way of saying
 “you can’t rely on this in any way”. For example if you think the
 module is going to be Yak::Shave, you’d create Acme::Yak::Shave. If
 the name settles down, then you can release a non Acme version. Then
 down the road you can delete the Acme:: version.

Some good suggestions in this thread, including from Neil, but the above
strikes me as an abuse of Acme::.

If I encounter a module in Acme:: I expect it to be a genuine silly
module, not a work-in-progress of a serious module. If everybody starts
putting unfinished serious modules in Acme, it makes it harder to find
the fun!

Smylers
-- 
http://twitter.com/Smylers2


Re: throw away module namespace

2014-12-14 Thread Karen Etheridge
All the suggestions so far are bang on -- I just have one more: prepan.org
is a great place to post your module and get early feedback on it!


Paging Andreas König… [was: throw away module namespace]

2014-12-13 Thread Aristotle Pagaltzis
* Chris Marshall devel.chm...@gmail.com [2014-12-12 17:35]:
 I thought I read somewhere that there is a way to have
 a non-comittal CPAN module in the sense that there was a namespace
 that *would* allow one to delete a module rather than having it in
 perpetuity?

IIRC there was a change to PAUSE recently in which uploading a dev
release will no longer lay claim to an as-yet-unclaimed namespace.

Unfortunately I am not having any luck finding the relevant postings
to confirm or deny exactly what changed.

But if that is the case then you could just upload every release as
a development release until you have settled the namespace question.

-- 
Aristotle Pagaltzis // http://plasmasturm.org/


Re: throw away module namespace

2014-12-13 Thread Chris Marshall
Thanks!  I appreciate all the suggestions.  --Chris

On Sat, Dec 13, 2014 at 12:56 PM, Karen Etheridge ka...@froods.org wrote:

 All the suggestions so far are bang on -- I just have one more: prepan.org
 is a great place to post your module and get early feedback on it!



throw away module namespace

2014-12-12 Thread Chris Marshall
All-

I'm working on some new module development
and I would like to make the progress available
via CPAN and for testing, I don't want to start
claiming package namespaces until things
settle down.

I thought I read somewhere that there is a
way to have a non-comittal CPAN module
in the sense that there was a namespace
that *would* allow one to delete a module
rather than having it in perpetuity?

Else, any recommendations on how to
accomplish the goal of not locking in the
namespaces until the organization of the
various components settle down?

Thanks in advance,
Chris

P.S.  This is for PDL3 and POGL2 development


Re: throw away module namespace

2014-12-12 Thread Yanick Champoux
On 14-12-12 11:33 AM, Chris Marshall wrote:
 Else, any recommendations on how to
 accomplish the goal of not locking in the
 namespaces until the organization of the
 various components settle down?

Just throwing ideas: an alternative would be to have your module lives
on GitHub, and use the fact that cpanm can also install modules directly
from there:

cpanm git://github.com/plack/Plack.git@devel

Of course, it means the distro won't be tested by CPANTesters, but you
could set up Travis to tide you over.

Joy,
`/anick


Re: throw away module namespace

2014-12-12 Thread Neil Bowers
Hi Chris,

 I'm working on some new module development and I would like to make the 
 progress available via CPAN and for testing, I don't want to start claiming 
 package namespaces until things settle down.
 
 I thought I read somewhere that there is a way to have a non-comittal CPAN 
 module in the sense that there was a namespace that *would* allow one to 
 delete a module rather than having it in perpetuity?

Some suggestions:

You could just create the module(s) in whatever namespace you think is right 
now, and mark it very clearly as alpha quality with anything and everything up 
for change. You could note it in the abstract and in the first paragraph of the 
DESCRIPTION.
There is nothing to stop you deleting that module down the road, other than not 
wanting to pull the rug from under anyone.
You could do all releases as developer releases. These will still be tested by 
CPAN Testers, but the fact that it’s a developer release further sends a 
message. The downside is that developer releases don’t appear on your author 
page on MetaCPAN, and are ‘invisible’ to the toolchain / ecosystem in various 
ways.
You could put the modules in Acme::, which is another way of saying “you can’t 
rely on this in any way”. For example if you think the module is going to be 
Yak::Shave, you’d create Acme::Yak::Shave. If the name settles down, then you 
can release a non Acme version. Then down the road you can delete the Acme:: 
version.

Neil



Re: throw away module namespace

2014-12-12 Thread Christian Walde
On Fri, 12 Dec 2014 17:33:58 +0100, Chris Marshall  
devel.chm...@gmail.com wrote:



All-

I'm working on some new module development
and I would like to make the progress available
via CPAN and for testing, I don't want to start
claiming package namespaces until things
settle down.

I thought I read somewhere that there is a
way to have a non-comittal CPAN module
in the sense that there was a namespace
that *would* allow one to delete a module
rather than having it in perpetuity?

Else, any recommendations on how to
accomplish the goal of not locking in the
namespaces until the organization of the
various components settle down?

Thanks in advance,
Chris

P.S.  This is for PDL3 and POGL2 development


That's a miscommunication because there is a module name registration  
mechanism that nobody ever uses.


Honestly, either put it in CHM-PDL3, or even better, just leave it on  
github.


Or are you looking for cpantesters results? I think you can also just  
upload it with -TRIAL in the dist filename and most of CPAN will disregard  
it as a dev version. You can check in #distzilla, #cpantesters and  
#toolchain to get information on these issues.


--
With regards,
Christian Walde