Re: Comment on module name Data::ETL

[Robert Wohlfarth]

ETL::$Brand - That's an excellent idea!

--
Robert W.


On Wed, May 4, 2016 at 12:15 PM Jed Lund  wrote:

> I would second the ETL::$Brand suggestion.  There isn't necessarily a
> consensus on how ETL should be done even outside the perl community.  I
> also think ETL::$Brand honors the perl TIMTOWDI culture and that allows for
> multiple ETL styles with overlapping function.
>
> Jed
>
> On Wed, May 4, 2016 at 6:27 AM, Smylers  wrote:
>
>> Robert Wohlfarth writes:
>>
>> > I'm weighing 3 ideas...
>> > 2. Create a top-level namespace for ETL.
>> >
>> > Idea 2 looks like so...
>> > * ETL
>> > * ETL::Extract
>> > * ETL::Extract::Excel
>> > * ETL::Extract::DelimitedText
>> > * ETL::Extract::XML
>> > * ETL::Load
>> > * ETL::Load::MSAccess
>>
>> Not necessarily. That would be effectively claiming the ETL:: namespace
>> is for your suite of modules.
>>
>> An alternative would be to create the ETL:: top-level namespace and then
>> put your framework under another level of hierarchy there, leaving space
>> for other ETL modules to share ETL::. As in:
>>
>> • ETL::$Brand
>> • ETL::$Brand::Extract
>> • ETL::$Brand::Extract::Excel
>> • ETL::$Brand::Extract::DelimitedText
>> • ETL::$Brand::Extract::XML
>> • ETL::$Brand::Load
>> • ETL::$Brand::Load::MSAccess
>>
>> — where $Brand is a word/phrase of your choice (either just a fanciful
>> name you like, or one you think sums up your particular ETL module suite
>> over other (potentially yet to be written) options.
>>
>> > #2 is short and sweet. On the downside, acronyms are context
>> > sensitive.
>>
>> If potential users of your module are likely to know the term ETL and
>> that's something they'd search for, then it's still a useful name. That
>> probably matters more than for somebody outside the field randomly
>> encountering the name of your module being able to tell instantly what
>> it's for.
>>
>> Obviously a name having both of those qualities would be ideal, but at
>> least somebody who encounters the ETL::Taupe::Extract module can look up
>> its docs, whereas it'd be sad for a would-be fan of your module never to
>> learn of its existence.
>>
>> Smylers
>> --
>> http://twitter.com/Smylers2
>>
>
> --
Robert Wohlfarth

Re: Comment on module name Data::ETL

[Jed Lund]

I would second the ETL::$Brand suggestion.  There isn't necessarily a
consensus on how ETL should be done even outside the perl community.  I
also think ETL::$Brand honors the perl TIMTOWDI culture and that allows for
multiple ETL styles with overlapping function.

Jed

On Wed, May 4, 2016 at 6:27 AM, Smylers  wrote:

> Robert Wohlfarth writes:
>
> > I'm weighing 3 ideas...
> > 2. Create a top-level namespace for ETL.
> >
> > Idea 2 looks like so...
> > * ETL
> > * ETL::Extract
> > * ETL::Extract::Excel
> > * ETL::Extract::DelimitedText
> > * ETL::Extract::XML
> > * ETL::Load
> > * ETL::Load::MSAccess
>
> Not necessarily. That would be effectively claiming the ETL:: namespace
> is for your suite of modules.
>
> An alternative would be to create the ETL:: top-level namespace and then
> put your framework under another level of hierarchy there, leaving space
> for other ETL modules to share ETL::. As in:
>
> • ETL::$Brand
> • ETL::$Brand::Extract
> • ETL::$Brand::Extract::Excel
> • ETL::$Brand::Extract::DelimitedText
> • ETL::$Brand::Extract::XML
> • ETL::$Brand::Load
> • ETL::$Brand::Load::MSAccess
>
> — where $Brand is a word/phrase of your choice (either just a fanciful
> name you like, or one you think sums up your particular ETL module suite
> over other (potentially yet to be written) options.
>
> > #2 is short and sweet. On the downside, acronyms are context
> > sensitive.
>
> If potential users of your module are likely to know the term ETL and
> that's something they'd search for, then it's still a useful name. That
> probably matters more than for somebody outside the field randomly
> encountering the name of your module being able to tell instantly what
> it's for.
>
> Obviously a name having both of those qualities would be ideal, but at
> least somebody who encounters the ETL::Taupe::Extract module can look up
> its docs, whereas it'd be sad for a would-be fan of your module never to
> learn of its existence.
>
> Smylers
> --
> http://twitter.com/Smylers2
>

Re: Comment on module name Data::ETL

[Smylers]

Robert Wohlfarth writes:

> I'm weighing 3 ideas...
> 2. Create a top-level namespace for ETL.
> 
> Idea 2 looks like so...
> * ETL
> * ETL::Extract
> * ETL::Extract::Excel
> * ETL::Extract::DelimitedText
> * ETL::Extract::XML
> * ETL::Load
> * ETL::Load::MSAccess

Not necessarily. That would be effectively claiming the ETL:: namespace
is for your suite of modules.

An alternative would be to create the ETL:: top-level namespace and then
put your framework under another level of hierarchy there, leaving space
for other ETL modules to share ETL::. As in:

• ETL::$Brand
• ETL::$Brand::Extract
• ETL::$Brand::Extract::Excel
• ETL::$Brand::Extract::DelimitedText
• ETL::$Brand::Extract::XML
• ETL::$Brand::Load
• ETL::$Brand::Load::MSAccess

— where $Brand is a word/phrase of your choice (either just a fanciful
name you like, or one you think sums up your particular ETL module suite
over other (potentially yet to be written) options.

> #2 is short and sweet. On the downside, acronyms are context
> sensitive.

If potential users of your module are likely to know the term ETL and
that's something they'd search for, then it's still a useful name. That
probably matters more than for somebody outside the field randomly
encountering the name of your module being able to tell instantly what
it's for.

Obviously a name having both of those qualities would be ideal, but at
least somebody who encounters the ETL::Taupe::Extract module can look up
its docs, whereas it'd be sad for a would-be fan of your module never to
learn of its existence.

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

Re: Comment on module name Data::ETL

[Nelson Ferraz]

Hi,

I noticed that your ETL modules are not designed to use a dimensional model
(facts and dimensions), so it may be better to have your own namespace
instead of using DataWarehouse namespace.

Since it is more generic than a DataWarehouse, I would say Data::ETL is a
reasonable option. In fact, the Data namespace is already used by other
modules that deal with some kind of ETL, for instance:

Data::CTable
Read, write, manipulate tabular data

On Wed, May 4, 2016 at 4:46 AM, Robert Wohlfarth 
wrote:

> This is all very helpful. I'm weighing 3 ideas...
> 1. Take Nelson up on his offer and name it something like
> Datawarehouse::ETL::Script.
> 2. Create a top-level namespace for ETL.
> 3. Make a new namespace like StructuredDataConverter.
>

-- 
Nelson Ferraz

Re: A question of permissions

[Neil Bowers]

Hi Buddy,

> After I uploaded my new module Date::Easy a while back, I got a failure 
> notice from PAUSE:

I only just noticed your email. PAUSE-related issues are better raised to 
modu...@perl.org , or you can send to both modules@ 
and module-authors.

>> This distribution name can only be used by users with permission for the
>> package Date::Easy, which you do not have. No modules will be indexed.
> 
> Of course, I had checked for that prior to uploading, but perhaps I'm looking 
> in the wrong place.  My understanding was that the permissions would be 
> listed here:
> 
>   http://www.cpan.org/modules/06perms.txt
> 
> but I don't see Date::Easy listed there.  Is there somewhere else I should be 
> looking?

I *think* that the problem is this line in your META.json file:

"provides" : {},

If you include a “provides” section in your dist’s metadate, then PAUSE will 
take that as the definitive list of packages in your dist, and won’t look at 
the code.

And PAUSE now requires that a dist includes a package where the name matches 
the dist name (ie dist Date-Easy should have a module Date::Easy), but there 
wasn’t such a module listed in “provides”, hence the warning.

I’ll raise a ticket on PAUSE, as I think it could be more helpful when the 
provides block is empty.

Cheers,
Neil