Re: [RFC] File::TVShow::Parse
It would be either the job of the install script or static install process to determine that the Perl is too old, yes. In the former case, it's commonly hard-blocked by a "use 5.XXX" statement in the Makefile.PL or Build.PL, in the legacy format, as META.json is only used for configure phase prereqs in this case. In the latter case it would be via the perl runtime prereq in META.json - and only by an installer new enough to understand all of this anyway. This is all just for what version of Perl you support, though; for your module version, as long as you have a declared Perl minimum version in one of these ways, either version format is fine. -Dan On Tue, Apr 16, 2019 at 5:09 PM John M. Gamble wrote: > I'm already on record on not supporting anything older than 5.10.1*. But > the reason I mentioned the META.* files is because I would think (well, > hope) that that in itself should be enough to prevent older Perls from > even looking at the package**. > > Therefore, if the package isn't ever downloaded by these older Perls, the > 'use' statement can use the all-integer format without problem. In theory. > > -john > > --- > * In two or three years I'll be changing that to 5.16.1. > > ** People who deliberately override that restriction aren't part of this > conversation. > > On Tue, April 16, 2019 2:59 pm, Dan Book wrote: > > It depends entirely what Perls you want to support. If you only want to > > support Perl 5.10 or newer, module versions in the dotted-decimal form > are > > fine as long as you always declare them as strings and don't use > > underscores. If you want to support older than that, you have to jump > > through some hoops or risk users getting the wrong behavior. > > > > For the 'use X' statement itself for declaring a minimum perl version of > a > > file, the '5.XXXYYY' format is still (always?) recommended, because it > > will > > make sure that running it on older Perls will result in a sensible error > > message. > > > > -Dan > > > > On Tue, Apr 16, 2019 at 3:54 PM John M. Gamble > wrote: > > > >> On Mon, April 15, 2019 12:46 pm, David Cantrell wrote: > >> > On Mon, Apr 15, 2019 at 12:04:24PM -0400, Dan Book wrote: > >> > > >> >> As a side note, remember that the X.Y.Z form of versions (with more > >> than > >> >> one decimal point) is a sequence of integers ... > >> > > >> > Sadly it's worse than that. > >> > > >> > There exists popular software management software out there written by > >> > idiots who think that 3.0014 > 3.1, so that rule applies even when > >> > you're using numbers in the form X.Y with a single decimal point. > >> Those > >> > people did a lot of hard work to break numeric comparisons, one of the > >> > few things that computers are any good at. > >> > >> Are we at the point where there is no reason to not use X.Y.Z? I recall > >> (I > >> think) the historical reasons for using the 5.00y00z format, but given > >> that minimum Perl versions are now specified in META.* files, surely > >> there's no real reason to keep doing that anymore? > >> > >> I say this while looking at all my modules, which still use the fraction > >> format. > >> > >> -john > >> > > >
Re: [RFC] File::TVShow::Parse
I'm already on record on not supporting anything older than 5.10.1*. But the reason I mentioned the META.* files is because I would think (well, hope) that that in itself should be enough to prevent older Perls from even looking at the package**. Therefore, if the package isn't ever downloaded by these older Perls, the 'use' statement can use the all-integer format without problem. In theory. -john --- * In two or three years I'll be changing that to 5.16.1. ** People who deliberately override that restriction aren't part of this conversation. On Tue, April 16, 2019 2:59 pm, Dan Book wrote: > It depends entirely what Perls you want to support. If you only want to > support Perl 5.10 or newer, module versions in the dotted-decimal form are > fine as long as you always declare them as strings and don't use > underscores. If you want to support older than that, you have to jump > through some hoops or risk users getting the wrong behavior. > > For the 'use X' statement itself for declaring a minimum perl version of a > file, the '5.XXXYYY' format is still (always?) recommended, because it > will > make sure that running it on older Perls will result in a sensible error > message. > > -Dan > > On Tue, Apr 16, 2019 at 3:54 PM John M. Gamble wrote: > >> On Mon, April 15, 2019 12:46 pm, David Cantrell wrote: >> > On Mon, Apr 15, 2019 at 12:04:24PM -0400, Dan Book wrote: >> > >> >> As a side note, remember that the X.Y.Z form of versions (with more >> than >> >> one decimal point) is a sequence of integers ... >> > >> > Sadly it's worse than that. >> > >> > There exists popular software management software out there written by >> > idiots who think that 3.0014 > 3.1, so that rule applies even when >> > you're using numbers in the form X.Y with a single decimal point. >> Those >> > people did a lot of hard work to break numeric comparisons, one of the >> > few things that computers are any good at. >> >> Are we at the point where there is no reason to not use X.Y.Z? I recall >> (I >> think) the historical reasons for using the 5.00y00z format, but given >> that minimum Perl versions are now specified in META.* files, surely >> there's no real reason to keep doing that anymore? >> >> I say this while looking at all my modules, which still use the fraction >> format. >> >> -john >> >
Re: [RFC] File::TVShow::Parse
It depends entirely what Perls you want to support. If you only want to support Perl 5.10 or newer, module versions in the dotted-decimal form are fine as long as you always declare them as strings and don't use underscores. If you want to support older than that, you have to jump through some hoops or risk users getting the wrong behavior. For the 'use X' statement itself for declaring a minimum perl version of a file, the '5.XXXYYY' format is still (always?) recommended, because it will make sure that running it on older Perls will result in a sensible error message. -Dan On Tue, Apr 16, 2019 at 3:54 PM John M. Gamble wrote: > On Mon, April 15, 2019 12:46 pm, David Cantrell wrote: > > On Mon, Apr 15, 2019 at 12:04:24PM -0400, Dan Book wrote: > > > >> As a side note, remember that the X.Y.Z form of versions (with more than > >> one decimal point) is a sequence of integers ... > > > > Sadly it's worse than that. > > > > There exists popular software management software out there written by > > idiots who think that 3.0014 > 3.1, so that rule applies even when > > you're using numbers in the form X.Y with a single decimal point. Those > > people did a lot of hard work to break numeric comparisons, one of the > > few things that computers are any good at. > > Are we at the point where there is no reason to not use X.Y.Z? I recall (I > think) the historical reasons for using the 5.00y00z format, but given > that minimum Perl versions are now specified in META.* files, surely > there's no real reason to keep doing that anymore? > > I say this while looking at all my modules, which still use the fraction > format. > > -john >
Re: [RFC] File::TVShow::Parse
On Mon, April 15, 2019 12:46 pm, David Cantrell wrote: > On Mon, Apr 15, 2019 at 12:04:24PM -0400, Dan Book wrote: > >> As a side note, remember that the X.Y.Z form of versions (with more than >> one decimal point) is a sequence of integers ... > > Sadly it's worse than that. > > There exists popular software management software out there written by > idiots who think that 3.0014 > 3.1, so that rule applies even when > you're using numbers in the form X.Y with a single decimal point. Those > people did a lot of hard work to break numeric comparisons, one of the > few things that computers are any good at. Are we at the point where there is no reason to not use X.Y.Z? I recall (I think) the historical reasons for using the 5.00y00z format, but given that minimum Perl versions are now specified in META.* files, surely there's no real reason to keep doing that anymore? I say this while looking at all my modules, which still use the fraction format. -john
Re: [RFC] File::TVShow::Parse
On Mon, Apr 15, 2019 at 12:04:24PM -0400, Dan Book wrote: > As a side note, remember that the X.Y.Z form of versions (with more than > one decimal point) is a sequence of integers ... Sadly it's worse than that. There exists popular software management software out there written by idiots who think that 3.0014 > 3.1, so that rule applies even when you're using numbers in the form X.Y with a single decimal point. Those people did a lot of hard work to break numeric comparisons, one of the few things that computers are any good at. To work around their deliberate bug you need to keep the non-integer part of your version numbers the same length, always. So use the strings "3.0014" and "3.1000" instead of the numbers 3.0014 and 3.1 if you want to use non-integers. Or just use integers. -- David Cantrell | Minister for Arbitrary Justice The voices said it's a good day to clean my weapons
Re: [RFC] File::TVShow::Parse
Best practice is to $VERSION all modules in your distribution, because then
other distributions can depend on a certain version of any module they are
using rather than only the main module. You can bump versions in modules
separately based on when each is updated, but generally it ends up being
simpler in the long run if you keep all versions the same, thus matching
the distribution version, and bump all of them each release. Authoring
tools like Dist::Zilla/Milla/Minilla can manage these versions for you (see
the Starter bundle's managed_versions option for Dist::Zilla), and
otherwise I wrote a tool that may be helpful:
https://metacpan.org/pod/perl-bump-version
As a side note, remember that the X.Y.Z form of versions (with more than
one decimal point) is a sequence of integers, thus leading zeroes in any
section are insignificant. Make sure not to accidentally use the X.Y form,
which in Perl is treated as a decimal number that isn't directly
compatible. Further reading:
http://blogs.perl.org/users/grinnz/2018/04/a-guide-to-versions-in-perl.html
-Dan
On Mon, Apr 15, 2019 at 9:35 AM Adam Spann wrote:
> I have completed the majority of the code for this module. Renamed it
> File::TVShow::Info as well.
>
> There are still a few things to do. But its main function of
> extracting key identifying information is complete.
>
> I am including the current README from the pod documentation.
>
> One question however:
>
> 1) I have separted some data and arrays containing regex patterns into
> seperate files
> E.G File:TVShow::EpisodeName.pm
> Do I need to VERSION this pm file. The expectation would be that
> this file would be updated and this would then
>require a minor version update to the File::TVShow::Info Note that
> VERSION is 0.01.0.0 so if EpsiodeName is updated
>Info would become 0.01.0.1 and a minor update to Info would make
> the version 0.01.1.0 with a major code change resulting in 0.02.0.0
>
>
> I look forward to hearing some feedback.
>
> Kind Regards,
> Adam Spann
>
> NAME
>
> File::TVShow::Info - Perl meta data extractor from file name for TV
> Show file.
>
> VERSION
>
> Version 0.01.0.0
>
> SYNOPSIS
>
> This module is intended to identify and extract nformation in the file
> name of a TV show. These details can then be accessed by calling the
> relevant methods. It does NOT attempt to read the contents of the file.
>
> Note: This module will be modelled off
> https://metacpan.org/pod/Video::Filename created by Behan Webster, but
> will focus on TV Shows only and with additional features.
>
> If the file name is parsed and can not be identified as a TV show then
> "is_tv_show" will return 0.
>
> use File::TVShow::Info;
> my $show = File::TVShow::Info->new('file');
>
> Methods
>
> new
>
> Create a Info object to extract meta information from the file name.
>
> my $show = File::TVShow::Info->new('file');
>
> Object attributes.
>
> Attributes may be accessed through $show->{attribute_name} however
> methods do exist for all required operations.
>
> * show_name: Name of the show.
>
> * original_show_name: This will contain the show name found in the
> file name without any modifications. This will only be defined if
> _isolate_name_year has found a year string within the file name such
> as name.2019, name.(2019), name 2018, name (2018)
>
> * season: Show season
>
> * episode: Show episode
>
> * episode_name
>
> * country
>
> * endep: (Naming under consideration) last Episode number found when
> file name contains SXXEXXEXX
>
> * year, month, date: Show date e.g 2019.03.03 This can be accessed
> using the method "ymd" Note: year will be defined in two cases. One:
> show name contains year. show_name. or Two: File name contains
> .MM.DD that are identified by date. These are mutually exclusive
> and no conflict is expected.
>
> * source
>
> * resolution: Show resolution 480p/720p and so on. This will be '' if
> not found.
>
> * release_group
>
> * is_subtitle
>
> * subtitle_lang
>
> * ext: File extension
>
> show_name
>
> Return the show name found in the file name.
>
> strip_show_name
>
> Return show_name after removing string delimiters
>
> original_show_name
>
> Return the original show name.
>
> This method will return the orginal show name if original_show_name is
> defined. This will be defined if show_name contains a year string
> () or
>
> If not defined it will return {show_name}
>
> season
>
> Return the season found in the file name. Return '' if {season} is not
> defined.
>
> season_to_int
>
> Return season as an integer
>
> episode
>
> Return the episode found in the file name. Return '' if {episode} is
> not defined.
>
> episode_to_int
>
> Return episode as an integer
>
>
Re: [RFC] File::TVShow::Parse
I have completed the majority of the code for this module. Renamed it
File::TVShow::Info as well.
There are still a few things to do. But its main function of
extracting key identifying information is complete.
I am including the current README from the pod documentation.
One question however:
1) I have separted some data and arrays containing regex patterns into
seperate files
E.G File:TVShow::EpisodeName.pm
Do I need to VERSION this pm file. The expectation would be that
this file would be updated and this would then
require a minor version update to the File::TVShow::Info Note that
VERSION is 0.01.0.0 so if EpsiodeName is updated
Info would become 0.01.0.1 and a minor update to Info would make
the version 0.01.1.0 with a major code change resulting in 0.02.0.0
I look forward to hearing some feedback.
Kind Regards,
Adam Spann
NAME
File::TVShow::Info - Perl meta data extractor from file name for TV
Show file.
VERSION
Version 0.01.0.0
SYNOPSIS
This module is intended to identify and extract nformation in the file
name of a TV show. These details can then be accessed by calling the
relevant methods. It does NOT attempt to read the contents of the file.
Note: This module will be modelled off
https://metacpan.org/pod/Video::Filename created by Behan Webster, but
will focus on TV Shows only and with additional features.
If the file name is parsed and can not be identified as a TV show then
"is_tv_show" will return 0.
use File::TVShow::Info;
my $show = File::TVShow::Info->new('file');
Methods
new
Create a Info object to extract meta information from the file name.
my $show = File::TVShow::Info->new('file');
Object attributes.
Attributes may be accessed through $show->{attribute_name} however
methods do exist for all required operations.
* show_name: Name of the show.
* original_show_name: This will contain the show name found in the
file name without any modifications. This will only be defined if
_isolate_name_year has found a year string within the file name such
as name.2019, name.(2019), name 2018, name (2018)
* season: Show season
* episode: Show episode
* episode_name
* country
* endep: (Naming under consideration) last Episode number found when
file name contains SXXEXXEXX
* year, month, date: Show date e.g 2019.03.03 This can be accessed
using the method "ymd" Note: year will be defined in two cases. One:
show name contains year. show_name. or Two: File name contains
.MM.DD that are identified by date. These are mutually exclusive
and no conflict is expected.
* source
* resolution: Show resolution 480p/720p and so on. This will be '' if
not found.
* release_group
* is_subtitle
* subtitle_lang
* ext: File extension
show_name
Return the show name found in the file name.
strip_show_name
Return show_name after removing string delimiters
original_show_name
Return the original show name.
This method will return the orginal show name if original_show_name is
defined. This will be defined if show_name contains a year string
() or
If not defined it will return {show_name}
season
Return the season found in the file name. Return '' if {season} is not
defined.
season_to_int
Return season as an integer
episode
Return the episode found in the file name. Return '' if {episode} is
not defined.
episode_to_int
Return episode as an integer
source
Return the source of tv show. Return '' if not defined. Yet to be
coded.
is_multi_episode
Return 1 if this is a multi-episode file SXXEXXEXX. Return 0 if false
This is true if {endep} is defined.
season_episode
Return SXXEXX or SXXEXXEXX for single or multi episode files. Return ''
if not created
This would only return an empty string if the show_name is not formated
as show_name.SXX.*
has_year
Return 1 if year is defined else return 0
year
Return the year found in the file name. Return '' if {year} is not
defined.
month
Return the month found in the file name. Return '' if {month} is not
defined.
date
Return the date found in the file name. Return '' if {date} is not
defined.
ymd
Return the complete date string as '.MM.DD' Ruturn '' if attributes
{year}, {month}, and {date} are not defined.
resolution
Return resolution found in the file name. Return '' if {resolution} is
not defined.
release_group
Return release_group found in the file name. Return '' if
{release_group} is not defined.
episode_name
Return episode_name. Return '' if {extra_meta} is not defined or can
not determine episode name.
Note: episode name MUST directly follow SXXEXX or it can not be found.
strip_episode_name
Re: [RFC] File::TVShow::Parse
Thanks for the suggestions. I have decided to go with Info. At this point support legacy regex appears pretty straight forward. But I agree. It will be removed. I run my code on an old mac mini, late 2009 which has perl 5.14 Thanks again for the feedback. Adam On Sun, 17 Mar 2019 at 04:09, John M. Gamble wrote: > I would tend toward Info myself. The existence of Video::Info is > irrelevant except for highlighting that Info is a valid choice. But I also > admit that's just me, and I tend to view Parse in a language context. > > Don't bother trying to support Perl versions less that 5.10. Last I > checked the (admittedly unscientific) surveys, 5.10 was the lowest version > that had a sizeable usage percentage, and on a personal level, I just > don't want to support Perls with flawed security. > > My current modules either have a minimum required versions of 5.10.1, or > 5.16.1, depending on whether I might have to deal with Unicode. I've never > had a complaint (I don't write pragmas or system-oriented code, so it's > never been anything I've need to worry about). > > -john > > On Thu, March 14, 2019 10:56 pm, Adam Spann wrote: > > Hello Everyone, > > > > I am considering a module to supplement Video::Filename written by > > Behan Webster. I have tried reaching out to him in the past couple of > > weeks. Submitting a patch to provide support for show > > name..mm.dd.ext > > > > > > In the mean time I have been considering if a specific module for TV > > Shows only might also be worth while, of course with additional > > features and support. > > > > See attached podtotext file. > > > > I have a few questions. > > > > 1) > > Would it be better to go with Parse, Meta, or Info since we are > > attempting to get meta data from from the file naming. There is > > already a Video::Info which does the deep dive into the file contents > > from what I have read. I have not used the module itself. > > > > 2) > > Should I keep support for perl below version 5.10 as versions below > > this do not support named groups in regex. I have seen on PerlMonks > > that there are still questions being asked by people using perl > > versions less than 5.10 > > > > > > Looking forward to hearing back. > > > > Best, > > Adam Spann > > > > >
Re: [RFC] File::TVShow::Parse
I would tend toward Info myself. The existence of Video::Info is irrelevant except for highlighting that Info is a valid choice. But I also admit that's just me, and I tend to view Parse in a language context. Don't bother trying to support Perl versions less that 5.10. Last I checked the (admittedly unscientific) surveys, 5.10 was the lowest version that had a sizeable usage percentage, and on a personal level, I just don't want to support Perls with flawed security. My current modules either have a minimum required versions of 5.10.1, or 5.16.1, depending on whether I might have to deal with Unicode. I've never had a complaint (I don't write pragmas or system-oriented code, so it's never been anything I've need to worry about). -john On Thu, March 14, 2019 10:56 pm, Adam Spann wrote: > Hello Everyone, > > I am considering a module to supplement Video::Filename written by > Behan Webster. I have tried reaching out to him in the past couple of > weeks. Submitting a patch to provide support for show > name..mm.dd.ext > > > In the mean time I have been considering if a specific module for TV > Shows only might also be worth while, of course with additional > features and support. > > See attached podtotext file. > > I have a few questions. > > 1) > Would it be better to go with Parse, Meta, or Info since we are > attempting to get meta data from from the file naming. There is > already a Video::Info which does the deep dive into the file contents > from what I have read. I have not used the module itself. > > 2) > Should I keep support for perl below version 5.10 as versions below > this do not support named groups in regex. I have seen on PerlMonks > that there are still questions being asked by people using perl > versions less than 5.10 > > > Looking forward to hearing back. > > Best, > Adam Spann >
[RFC] File::TVShow::Parse
Hello Everyone,
I am considering a module to supplement Video::Filename written by
Behan Webster. I have tried reaching out to him in the past couple of
weeks. Submitting a patch to provide support for show
name..mm.dd.ext
In the mean time I have been considering if a specific module for TV
Shows only might also be worth while, of course with additional
features and support.
See attached podtotext file.
I have a few questions.
1)
Would it be better to go with Parse, Meta, or Info since we are
attempting to get meta data from from the file naming. There is
already a Video::Info which does the deep dive into the file contents
from what I have read. I have not used the module itself.
2)
Should I keep support for perl below version 5.10 as versions below
this do not support named groups in regex. I have seen on PerlMonks
that there are still questions being asked by people using perl
versions less than 5.10
Looking forward to hearing back.
Best,
Adam Spann
NAME
File::TVShow::Parse
VERSION
Version 0.01
SYNOPSIS
This module is intended to parse and identify information in the file
name of a TV show. These details can then be accessed by calling the
relevant methods. It does NOT attempt to read the contents of the file.
Note: This module will modelled off Video::Filename created by Behan
Webster, but will focus on TV Shows only and with additional features.
If the file name is parsed and can not be identified as a TV show then
"is_tv_show" will return 0.
use File::TVShow::Parse;
my $show = File::TVShow::Parse->new('file');
Methods
new
Create a Parse object to extract meta information from the file name.
my $show = File::TVShow::Parse->new('file');
Data held in the object.
* show_name: Name of the show.
* original_show_name: This will contain the show name found in the
file name without any modifications This will only be defined if
_isolate_name_year has found a year string within the file name such
test.2019, test.(2019), test 2018, test (2018)
* season: Show season
* episode: Show episode
* endep: (Naming under consideration) last Episode number found when
file name contains SXXEXXEXX
* year, month, date: Show date e.g 2019.03.03 This can be accessed
using the method "ymd" Note: year will be defined in two cases. One:
show name contains year Two: File name contains .MM.DD that are
identified by date.
* resolution: Show resolution 480p/720p and so on. This will be '' if
not found.
* ext: File extension
show_name
Return the show name found in the file name.
original_show_name
Return the original show name. This method will return the orginal show
name if defined original_show_name will be defined if show name
contained a year string () or If not defined it will return
{show_name}
season
Return the season found in the file name. Return '' if no season is
found.
episode
Return the episode found in the file name. Return '' if no episode
found.
is_multi_episode
Return 1 if this is a multi-episode file SXXEXXEXX. Return 0 if false
season_episode
Return SXXEXX or SXXEXXEXX for single or multi episode files. Return ''
if not created
has_year
Returns 1 if $self->{year} is defined else return 0
year
Return the year found in the file name. Return '' is no year found.
month
Return the month found in the file name. Return '' if no month found.
date
Return the date found in the file name. Return '' if no date found.
ymd
Return the complete date string as '.MM.DD' Ruturn '' if no
attributes year, month, or date.
resolution
Return resolution found in the file name. Return '' if no resolution
found.
episode_name (Under consideration, difficult to isolate and often ommited)
ext
Return file extension.
is_tv_show
Return 1 if identified as a TV Show. Default is 0
is_by_date
Return 1 if by date. Default is 0
is_by_season
Return 1 if by season. Default is 0
_isolate_name_year
AUTHOR
Adam Spann, ""
BUGS
Please report any bugs or feature requests to "bug-file-tvshow-parse at
rt.cpan.org", or through the web interface at
. I
will be notified, and then you'll automatically be notified of progress
on your bug as I make changes.
SUPPORT
You can find documentation for this module with the perldoc command.
perldoc File::TVShow::Parse
You can also look for information at:
* RT: CPAN's request tracker (report bugs here)
* AnnoCPAN: Annotated CPAN documentation
* CPAN Ratings
