Rate a distribution
Find a distribution you would like to review:
Recent reviews (RSS feed)
Works as advertised, but the design of the module requires an extreme amount of API requests to fetch ticket information, making its use both slow and producing too much load on the servers of the API provider.
For example, if I want a list of tickets created after some date or all tickets in the queue, the API provides the '/search/ticket' endpoint that returns a list of found ticket IDs together with their subject lines. Pretty useful as the basis to find a ticket you want.
This module, however, discards the subjects and returns only IDs. If you do want those subjects, you have to call another method that makes another API request, *for each ticket.*
The same issue exists with individual tickets too. If I want to read the ticket and all of the replies to it, the API provides the '/ticket/###/history' endpoint that returns all of that information.
The module, however, requires you get_transaction_ids() for IDs of all the individual items on the ticket, which along with comments includes status changes, for example. And once you have those IDs, you have to request each individual transaction using get_transaction().
Consider a single ticket with 5 comments, status change from `new` to `open`, `bug` tag added, and then status changed from `open` to `resolved`. Using the API with `curl`, I can obtain all of that information in a single API request (login credentials can be part of the URL).
But if I use this module, I have to make 1 request to get transaction IDs, then 8 additional requests to get each individual "transaction."
If all I want is a list of all RT tickets with subject lines for perl6 queue, I can't even reasonably use the module, as instead of 1 API request I can do with `curl`, I will have to make one per ticket I want, resulting in over 1300 requests for the full queue.
Despite promising to be the API client, this module is entirely unusable for my simple and non-exotic task.
This is a response from the author to the two reviews posted below. For a very long time, Net::FullAuto was experimental software, and for years there were warnings in the sparse documentation that this software was not ready for general use. That said, at the time the reviews below were posted, many of the points raised in these reviews were genuine issues, most of which have since been remediated or explained. The POD documentation is now complete and up to date. It bears little resemblance to the sparse documentation these reviewers encountered more than a year ago. That said, the accusation of malicious intent without and any evidence to support this assertion other than complexity the reviewer had no wish to navigate, is irresponsible - and that is being kind. His very words "I suspect" demonstrate his lack of true inquiry, and his eagerness to denigrate and even slander the author without adequate foundation, is something the author hopes is transparent to others. That said, I will address these concerns because some of them are valid, and are concerns that others will share.
Again, documentation is NOW complete, up to date, and accurate.
"Marketing" style language has been mostly removed, and any that remains is informational and more of what one would expect to find in "documentation".
It's true that the installation of this module is highly customized. Net::FullAuto has over 100 dependencies on other modules, and many of those modules have long chains of their own dependencies. To get all these to install successfully in a 100% automated fashion literally took years to achieve. Conventional Perl distribution tools were largely abandoned because they simply couldn't do the job without requiring significant manual intervention and expertise from the user. Many of these tools have since evolved, but there are still multiple reasons that they cannot yet provide a complete solution for installing Net::FullAuto. Net::FullAuto is workload automation software designed to compete with packages like Chef, Ansible, Puppet and others. Anyone familiar with those frameworks know how complex and challenging they are to install and work with. The goal of the FullAuto project was to come up with a framework that was not only easier to work with than these others, but significantly easier. That goal is met only with a fully automated installation of the tool and all its dependencies. It's hard to promote "workload automation software" as ground breaking if it fails to fully automate its first genuine workload - its own installation.
It's true that the CPAN TESTERS service has been disabled. Because of the large number of dependencies, The Net::FullAuto install uses "continuous integration". In other words, dependencies will always be updated to the latest version. The CPAN Tester community use hosts with very sensitive configurations, and encountered problems with modules being updated automatically. To conform to the needs of the CPAN Testers would mean putting an incredible burden on ordinary users requiring them to perform dozens (even hundreds) of manual installation tasks they have neither the time, patience nor expertise for. Users are warned of this behavior when first endeavoring to install Net::FullAuto, and are advised to use a host, or alternate secondary Perl installation where automated updates of modules is not an issue.
'sudo' is used only with Amazon EC2 hosts as of this writing. Net::FullAuto needs administrative privileges to be installed on EC2 hosts, and users have to go through elaborate setup steps to enable an Amazon account with the necessary privileges. Their consent is assumed for these reasons.
There are a number of small utilities bundled with the distribution. They are all open source and free of any restrictions. They may be removed and stored elsewhere (like sourceforge or github) in the future. The use of Figlet fonts is explained in the POD documentation.
It is true that a number of accepted CPAN standards have been abandoned or significantly altered. There are good reasons the standards exist, but also good reasons for having to avoid them. The decision was made that a FULLY automated installation of Net::FullAuto and ALL of its hundreds of dependencies justified the decisions made. All are subject to change as both Net::FullAuto and the CPAN evolve.
Net::FullAuto is unique as it uses a PERSISTENT connection to communicate with remote nodes. This functionality took 16 long years to perfect, but is now ready to do the kind of robust workload automation only dreamed about - until now.
I hope you will give it a chance to impress you, and I hope you will choose to open tickets and work with me and my team to improve Net::FullAuto, rather than post a permanent negative review over a temporary concern.
If safety and security are concerns - as they should be, please experiment with Net::FullAuto on a public cloud or other disposable machine image before installing on a more sensitive host. This video will walk you through the entire setup process on Amazon EC2:
I switched to this module because I needed to use UNION [ALL] in my queries and it was a nice drop-in replacement for SQL::Abstract and SQL::Abstract::Limit.
Cons: more heavyweight (requires Moo), limited operations/methods, can only handle IPv4 and not IPv6. Pros: some operations are faster than competing modules, e.g. validation. See also: NetAddr::IP, Net::CIDR.
Aside from being Moo-based (which, makes it a bit more heavyweight and with more dependencies), doesn't yet offer anything extra or more methods compared to previously existing modules like NetAddr::MAC.
great tool, i love it.
would be great if below change is implemented:
from: return $self->add_image_entry("$filename");
to: return $self->add_image_entry("$filename", $type);
A well-intentioned module with honest documentation, but not really appropriate for use in any serious production context. I found it rife with errors (such as identifying locations in the U.S. east coast as existing in Central Time) and the output was often expressed in non-standard terms that would make DateTime::TimeZone choke.
Time Zones are the worst, and I appreciate the effort to write a self-contained module like this, but at this time the only universal options I can find for turning geolocational coordinates into usably standard time-zone strings involve using public service APIs, such as Google Maps Time Zone API.
In case you didn't know, neilb ( at search.cpan.org/~neilb/ ) uses this module as an example of a deprecated module. Furthermore, he uses it as an example of how a distribution maintainer can set the x_deprecated flag ( as explained at neilb.org/2015/01/17/deprecated-metad... ).
This module more or less correctly conjugates English verbs. There is also something called Lingua-EN-Inflexion but this module looked a lot simpler, so I used this one.
Your default example does not work.
Original Input '40 1/2 N OLD MASSACHUSETTS AVE APT 3B Washington Valley Washington 98100: HOLD MAIL'
Cleaned Input '40 1/2 N OLD MASSACHUSETTS AVE APT 3B WASHINGTON VALLEY WASHINGTON 98100 HOLD MAIL '
Country address format 'US'
Address type 'unknown'
Non matching part '40 1/2 N OLD MASSACHUSETTS AVE APT 3B WASHINGTON VALLEY WASHINGTON 98100 HOLD MAIL '
Error descriptions 'non matching section : 40 1/2 N OLD MASSACHUSETTS AVE APT 3B WASHINGTON VALLEY WASHINGTON 98100 HOLD MAIL '
Warning description ''
Case all '40 1/2 N Old Massachusetts Ave Apt 3b Washington Valley Washington 98100 Hold Mail '
here is test.pl:
my %args =
country => 'US',
auto_clean => 1,
force_case => 1,
abbreviate_subcountry => 0,
abbreviated_subcountry_only => 1,
force_post_code => 0
my $address = Lingua::EN::AddressParse->new(%args);
my $error = $address->parse("40 1/2 N OLD MASSACHUSETTS AVE APT 3B Washington Valley Washington 98100: HOLD MAIL");
print "report $error\n";
I have being programming in Perl for some years already, but decided to lookup some better implementation of sets after start learning Python (which implemented is part of standard distribution).
Before that, I used hashes for the same results, which indeed I think is what the majority of Perl programmers do.
Honestly, Set::Tiny should be turned to a standard module. It is a solid implementation, easy to use and with zero dependencies. After using it I really got addicted to it when I need set operations.
I love this module. Lets you do anything with OpenLDAP. It's all there. Never let me down.
I regularly use Data::Dumper, and recently found a simpler version of that, Data::Dump, Now I found a wonderful module. I am going to stick to this module over others. Thanks dev.
To the previous reviewers and others checking these reviews: Starting release 0.20, Test::Dependencies will only test perl files (*.pl, *.pm, *.t and scripts starting with a perl shebang line), or a list of files explicitly passed.
Your concerns presumably have been addressed.
It does not produce any raw output or it is not explained how to produce it. It makes PatchReader almost useless
I'd say in terms of footprint and runtime performance, this module is average (it's not the most lightweight nor the fastest pure-perl object system, not to mention against XS ones). See my Bencher::Scenarios::Accessors for a comparison, e.g. metacpan.org/pod/Bencher::Scenario::A... and metacpan.org/pod/Bencher::Scenario::A... .
One drawback of using Mojo::Base and Object::Simple is its similar but slightly different and incompatible syntax with the Moo* family, so your code is not "upgradable" to Moo or Moose once you need more features. And often you'll end up wanting them, e.g. one day you'll probably read about the wonders of method modifiers (before, after, around), or roles, or wanting to have a lazy constructor, or triggers, and so on.
I'd recommend instead Mo. It's more lightweight than Object::Simple and you can do default value, builder, ro/rw, required, even coercion. But the features are modular and you only pay for what you use. And once you need more features later, you normally should be able to just replace 'use Mo' in your code with 'use Moo' or 'use Moose'.
Of course, this point is moot if you don't care about compatibility/upgradability to Moo*.
Thanx a lot. Does solve all may problems in CSV: newlines, UTF-8
Very recommendable !
It's a pity this module is so slow. Unicode::ICU::Collator, which is a wrapper around the ICU library, is much, much faster. Unfortunately it doesn't work with ActivePerl and MinGW in Windows, since the Visual C ICU DLLs don't seem to be compatible with MinGW; the module crashes at ucol_open().
I was having a real bad time with Net::SSH2 module in Windows, but after finding out this module I could happily finish my job!
The module is not only functional (something I was not being able to get with Net::SSH2, even with the most mundane commands), the interface is much easier to use.
And, as the cherry on the top, this module will give you an instance of Net::SFTP::Foreign reusing your same SSH session.
I totally recommend this module as a replacement for Net::SSH2 if you're at a Windows OS.