Re: RFC: Fixing fallback tempdir location on Win32

2015-05-21 Thread Jan Dubois 
On Thu, May 21, 2015 at 1:14 PM, David Golden x...@xdg.me wrote:
 First, I'd want someone to check if it returns %USERPROFILE% exactly or some
 path under it.

Only tested on Win7; is seems to append a backslash to it:

Z:\type gettemppath.pl
use strict;
use warnings;

use Win32::API;

print $_=$ENV{$_}\n for qw(TMP TEMP USERPROFILE);
delete $ENV{$_} for qw(TMP TEMP);
my $GetTempPath = new Win32::API('kernel32', 'GetTempPath', 'NP', 'N') or die;
my $buffer =   x 280;
my $len = $GetTempPath-Call(length $buffer, $buffer);
print substr($buffer, 0, $len), \n;

Z:\perl gettemppath.pl
TMP=C:\Users\gecko\AppData\Local\Temp
TEMP=C:\Users\gecko\AppData\Local\Temp
USERPROFILE=C:\Users\gecko
C:\Users\gecko\

And tested separately, it will normalize forward slashes to backslashes as well.

Cheers,
-Jan

Re: RFC: Fixing fallback tempdir location on Win32

2015-05-21 Thread Jan Dubois 
On Thu, May 21, 2015 at 8:38 AM, David Golden x...@xdg.me wrote:
 We have various unsolved tickets (see end for links) about
 File::Temp/File::Spec failing on Windows due to taint, where
 File::Spec-tmpdir returns the root directory, which many Windows users
 can't actually write to.  (Context: File::Spec checks -w on candidate temp
 dirs, but that can be true on Windows, yet the ACLs can prevent files from
 being written there. See perlport on -X operators.)

I'm curious *why* tmpdir() would return the root directory. Normally
%TMP% should be setup to point to the Temp directory inside the local
APPDATA directory for regular users, or to %windir%/Temp when running
as a service.

 After discussions on #toolchain, I have two proposals:

 (1)  That File::Temp fall back to the following if it can't create a
 temporary directory in the directory that is the result of
 File::Spec-tmpdir:


 File::Spec-catdir(Win32::GetFolderPath(Win32::CSIDL_LOCAL_APPDATA),q{Temp})

Seems sensible to me, although I'm not sure what that returns for
processes running as a service.

 (2) That File::Spec::Win32 put that same path after environment variables
 paths but before all existing fallback paths
 (https://metacpan.org/source/SMUELLER/PathTools-3.47/lib/File/Spec/Win32.pm#L74-78)

I just noticed the the GetTempPath() API will fall back to
%USERPROFILE% if neither %TMP% nor %TEMP% are set. Maybe that variable
should be checked as well, for consistency with other apps?

https://msdn.microsoft.com/en-us/library/windows/desktop/aa364992%28v=vs.85%29.aspx

Cheers,
-Jan

Re: How To Build A Perl Package Database

2012-12-31 Thread Jan Dubois 
On Fri, Dec 28, 2012 at 4:18 PM, Leon Timmermans faw...@gmail.com wrote:

  Anyways, I just wanted to say that without putting some restrictions on
 how
  modules (and corresponding scripts) can be installed, creating a package
  manager would seem to get even more complex than ExtUtils::Makemaker...
 :)

 What kind of restrictions are you thinking about exactly?


Mostly I would prohibit sharing of directories between Perl installations,
and even within a single installation, the sharing of directories between
install locations.

E.g. the default configuration right now has $Config{installbin} and
$Config{installsitebin} pointing to the the same directory. This means that
if you install ExtUtils::ParseXS from CPAN, you end up with the new version
of the module in $Config{installsitelib}, but the xsubpp script installed
into $Config{installsitebin} will overwrite the core version already in
$Config{installbin} because they are the same directory.

This means it is now impossible to remove the ExtUtils::ParseXS module from
the site install location and reverting to the core version.

Even if you don't care about delete functionality in your package
manager, you may still want to preserve the integrity of core install.
Otherwise it is possible that the package manager updates a package it
relies upon itself that breaks the package manager. Then it is impossible
to fix this situation for a regular user without doing a complete reinstall
of Perl itself.

For this reason the ActivePerl package manager explicitly removes the
site directories from @INC and only uses the modules originally included
in the distribution.

Cheers,
-Jan

Fwd: How To Build A Perl Package Database

2012-12-27 Thread Jan Dubois 
-- Forwarded message --
From: Jan Dubois j...@activestate.com
Date: Thu, Dec 27, 2012 at 5:40 PM
Subject: Re: How To Build A Perl Package Database
To: Leon Timmermans faw...@gmail.com


On Thu, Dec 20, 2012 at 2:42 AM, Leon Timmermans faw...@gmail.com wrote:

 On Mon, Dec 17, 2012 at 9:36 AM, Tim Bunce tim.bu...@pobox.com wrote:
  A separate install database for each install location seems like the only
  workable approach.

 One minor complication of that is the strictest sense an install
 location isn't all that well defined. Or perhaps I should say every
 dist has 8 install locations with unspecified relationship on the
 filesystem (lib, arch, bin, script, libdoc, bindoc, libhtml, binhtml).
 In practice you may want to use lib *and* arch (they are never used
 simultaneously, but stuff in lib may be shared over different perl
 installations, contrary to arch which should be for one specific
 install).


I wonder if it isn't time to deprecate all the complex install combinations
that may have made sense when hard disks was rather limited.

In ActivePerl we enforce a pretty simplified install layout to be able to
create an intuitive package manager:

   - no sharing of directories between different versions
   - every install area has its own bin, etc, lib, and html subdirectories
   - the etc subdirectory records packages installed in that location

Here is how PPM looks (on my Mac, but it is rather similar on Windows or
Unix systems too):
$ ppm area
┌┬──┬┐
│ name   │ pkgs │ lib│
├┼──┼┤
│ user*  │   38 │ /Users/jan/Library/ActivePerl-5.16/lib │
│ (site) │  n/a │ /usr/local/ActivePerl-5.16/site/lib│
│ (perl) │  245 │ /usr/local/ActivePerl-5.16/lib │
└┴──┴┘

$ ls /Users/jan/Library/ActivePerl-5.16
bin  etc  html lib

$ ppm query XML
┌──┬─┬─┬──┐
│ name │ version │
abstract│ area │
├──┼─┼─┼──┤
│ XML-NamespaceSupport │ 1.11│ a simple generic namespace support
class│ user │
│ XML-Parser   │ 2.41-r1 │ A perl module for parsing XML
documents │ perl │
│ XML-SAX  │ 0.99│ Simple API for
XML  │ user │
│ XML-SAX-Base │ 1.08│ Base class for SAX Drivers and
Filters  │ user │
│ XML-Simple   │ 2.20│ Easily read/write XML (esp config
files)│ perl │
│ XML-Stream   │ 1.23│ Creates an XML Stream connection and
parses return data │ user │
└──┴─┴─┴──┘
 (6 packages installed matching 'XML')

$ ppm files XML-Stream
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/IO/Select/Win32.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/Namespace.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/Node.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/Parser.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/Parser/DTD.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/Tree.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/XPath.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/XPath/Op.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/XPath/Query.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/XPath/Value.pm
/Users/jan/Library/ActivePerl-5.16/lib/auto/XML/Stream/.packlist

$ ppm remove XML-NamespaceSupport
XML-NamespaceSupport: required by XML-SAX
ppm remove failed: No packages uninstalled

Having a separate perl/bin and perl/site/bin and perl/vendor/bin is
somewhat inconvenient for adding things to the $PATH, but it makes it
possible to install an updated core package into the site directory, and
later uninstall it without breaking the original core version. We don't use
perl/vendor but instead merge all pre-installed packages into the core
directories to keep $PATH a little shorter.

Anyways, I just wanted to say that without putting some restrictions on how
modules (and corresponding scripts) can be installed, creating a package
manager would seem to get even more complex than ExtUtils::Makemaker... :)

Cheers,
-Jan

RE: How to have Perl 5 and Perl 6 cohabitate nicely on CPAN

2010-04-15 Thread Jan Dubois 
On Thu, 15 Apr 2010, Barbie wrote:
 On Thu, Apr 15, 2010 at 08:56:04AM -0600, Curtis Jewell wrote:
  Why don't we make the .cpan/.c6pan file (.c6pan) a JSON file, generated
  by PAUSE once the tarball is uploaded, with whatever information is
  required (a reference to the tarball, what version of perl is required,
  etc.) in order, when that file is passed to a CPAN client, to download
  and install the tarball.
 
 This is essentially how PPM works. The PPD file points to a tarball, via
 an extension to the OSD file format. It would be easier to generate an
 installation configuration file, supported by a new installer that can
 cope with the double-click install of several OSes these days, than
 changing the package archive format.

PPM4 actually supports putting the PPD file inside the tarball.  When the
tarball is downloaded with a .ppmx extension, then the client knows to
extract the .ppd from inside the file and install everything else according
to this .ppd file.

The big problem with this scheme is though that is doesn't allow you
to install prerequisites using this mechanism: You can double-click on
a .ppmx file in a web browser and it can be downloaded and installed
automatically.  The ppm installer however no longer knows where the file
came from, so it cannot look for prerequisites in the same place.

This places the burden of installing prerequisites on the user, making
the mechanism less useful than originally expected.

One way around this would be to embed the file location inside the tarball
itself, but that doesn't work if the tarballs may be mirrored to multiple
locations.

It would be nice if browsers would include the download URL in an alternate
data stream (where possible, e.g. NTFS), but it looks like they only store
the Internet.Zone information...

Cheers,
-Jan

RE: How to have Perl 5 and Perl 6 cohabitate nicely on CPAN

2010-04-15 Thread Jan Dubois 
On Thu, 15 Apr 2010, Barbie wrote:
 On Thu, Apr 15, 2010 at 12:50:29PM -0700, Jan Dubois wrote:
 
  PPM4 actually supports putting the PPD file inside the tarball.  When the
  tarball is downloaded with a .ppmx extension, then the client knows to
  extract the .ppd from inside the file and install everything else according
  to this .ppd file.
 
  The big problem with this scheme is though that is doesn't allow you
  to install prerequisites using this mechanism: You can double-click on
  a .ppmx file in a web browser and it can be downloaded and installed
  automatically.  The ppm installer however no longer knows where the file
  came from, so it cannot look for prerequisites in the same place.
 
 The last time I used PPM it was able to support multiple repositories,
 in the same way apt or yum does. I also thought it was able to install
 prerequisites from these if a local ppd wasn't found. I'd certainly like
 to see a double-click installer work like that :)

Yes, it certainly downloads prerequisites from the configured repositories.
I was talking about downloading .ppmx files from some random website that
you didn't configure first as a repository in the PPM client.  The double-
clicked file is not able to download additional prerequisites from that
random website it came from itself.  Think private/internal repository
of a bunch of interdependent modules.

Once you have to configure the web site as a repo there isn't much advantage
of installing modules via the browser compare to installing them with the
PPM client:

ppm repo add random http://random.example.com/repo
ppm install my-random-module

Cheers,
-Jan

RE: Trimming the CPAN - Automatic Purging

2010-03-26 Thread Jan Dubois 
On Fri, 26 Mar 2010, Arthur Corliss wrote:
 But what the hell do I know.  I don't run a *CPAN* mirror, so I must be
 freaking clueless...

It's not about what you know, but about what you are willing to
do yourself.

At some point you have to accept that the people who *do* the work
decide *how* they do it.

There is not much point in just talking to volunteers that they should
not be doing something but instead be doing something else if you are
not willing to take the burden of doing this other thing yourself.

Volunteers are not free labor that the talking masses can direct with
majority votes. :)

Cheers,
-Jan

RE: CMSP 22. Clarify author field

2009-10-30 Thread Jan Dubois 
Jarkko wrote:
 One point about contact points comes to mind: do we currently
 allow/mention/encourage *multiple* contact addresses (be they email
 addresses or something else)

Yes, we do:

http://module-build.sourceforge.net/META-spec.html#author

| author
|
| Example:
|
|   author:
| - Ken Williams kwilli...@cpan.org
|
| (Spec 1.1) [required] {list of strings} A YAML sequence indicating the
| author(s) of the distribution. The prefered form is author-name
| email-address.

As I wrote previously in this thread, I normally put the original author's
name in the list without email address and then add myself with email address
at the end if I'm just maintaining the code on CPAN but haven't actually
authored it.  It still feels wrong though.

Cheers,
-Jan

RE: CMSP 22. Clarify author field

2009-10-09 Thread Jan Dubois 
On Fri, 09 Oct 2009, David Golden wrote:
 Though to be fair, author is currently *required*, and I like the
 idea that there be a required point of contact. However, I don't like
 the idea of a mandatory resources field.

 How about if it gets renamed auth and the description is author or
 designated authority to respond to issues.

 Doesn't that accomplish what we need?

I would prefer maintainer to make it absolutely clear that the contact
in that field does not claim authorship of the distribution.

I always feel uneasy to put my name/email address into author when all
I'm doing is keeping the module in working condition on CPAN. I then
still include the original author (without email address) to provide
some kind of attribution.

My sentiments would largely remain the same if the field was just
renamed to auth(ority), as I would still feel that the original author
should somehow be mentioned too.

But if it was just maintainer then there is no problem dropping
all previous authors who are no longer involved in the maintenance
(they still get their credit in the POD section on authorship and
copyright anyways).

I think it would also be good to require (or at least recommend) that
this field contains a list of email addresses, and not just some free
format text. If you cannot contact someone through this field, then the
information belongs in the POD and not into META.yml.

Cheers,
-Jan