Re: [PD] standard paths for externals

[Roman Haefeli]

On Fri, 2018-07-13 at 14:27 -0300, Alexandre Torres Porres wrote:
> 
> 
> 2018-07-13 11:12 GMT-03:00 Roman Haefeli :
> > So, does that mean the [declare]-flags -stdlib and -stdpath are
> > obsolete now?

Oops, bad wording on my part. I should have said 'in the declare-path
branch' instead of 'now' as readers might think it was already changed
in Pd, which is _not_ the case. I'm talking about a feature branch that
  possibly/hopefully makes it into Pd. 

> yes, and this was mentioned in this thread already - but it is kept
> there for backwards compatibility concerns, for not to have a change
> in behaviour from one version to another, so your old configuration
> still works 

Alright, that's absolutely correct. Old flags still work with old
layout, new flags work with new layout. So there is no problem with the
transition. Thanks for the clarification. 

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Alexandre Torres Porres]

2018-07-13 11:12 GMT-03:00 Roman Haefeli :
>
>
> So, does that mean the [declare]-flags -stdlib and -stdpath are
> obsolete now?
>

yes, and this was mentioned in this thread already - but it is kept there
for backwards compatibility concerns, for not to have a change in behaviour
from one version to another, so your old configuration still works
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Alexandre Torres Porres]

This is not a switch in behaviour as I see it, since you can keep things as
they are and the behaviour is still the same. Hence, no compatibility
breakage here.

Now, if you wanna do things differently, in a new way, as another option,
then this is provided and you should adapt your patches.

So it is a matter of deciding wether if it is worth to change your setup or
not...

cheers

2018-07-13 11:12 GMT-03:00 Roman Haefeli :

> On Thu, 2018-06-14 at 16:32 -0300, Alexandre Torres Porres wrote:
> > 2018-06-14 15:35 GMT-03:00 Roman Haefeli :
> > > Is this the idea?
> >
> > Yes! And it's working like that in my tests.
>
> Ok, it's working for me, too. I see significant progress in that (after
> having cleared all preferences) I end up with a "working" setup by
> clicking myself through the defaults. Things get downloaded to
> ~/Documents/Pd/externals, which was automatically created added to the
> search paths. After installing externals through 'Find externals', I
> can load them by [declare -lib ] and [declare -path ].
>
> So, does that mean the [declare]-flags -stdlib and -stdpath are
> obsolete now?
>
> I can't spot any problems with the branch feature/declare-path, but
> virtually all of my patches are broken with it because of incompatible
> [declare] flags. I like the 'new way' much better, but I wonder what is
> a good path to get there. It's actually an easy thing to replace all
> occurences of -stdlib/-stdpath with -lib/path. But switching behaviour
> from one version of Pd to the next seems bold.
>
> Roman
>
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Roman Haefeli]

On Thu, 2018-06-14 at 16:32 -0300, Alexandre Torres Porres wrote:
> 2018-06-14 15:35 GMT-03:00 Roman Haefeli :
> > Is this the idea?
> 
> Yes! And it's working like that in my tests.

Ok, it's working for me, too. I see significant progress in that (after
having cleared all preferences) I end up with a "working" setup by
clicking myself through the defaults. Things get downloaded to
~/Documents/Pd/externals, which was automatically created added to the
search paths. After installing externals through 'Find externals', I
can load them by [declare -lib ] and [declare -path ].

So, does that mean the [declare]-flags -stdlib and -stdpath are
obsolete now?

I can't spot any problems with the branch feature/declare-path, but
virtually all of my patches are broken with it because of incompatible
[declare] flags. I like the 'new way' much better, but I wonder what is
a good path to get there. It's actually an easy thing to replace all
occurences of -stdlib/-stdpath with -lib/path. But switching behaviour
from one version of Pd to the next seems bold.

Roman






signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Dan Wilcox]

> On Jun 14, 2018, at 9:44 PM, pd-list-requ...@lists.iem.at wrote:
> 
> User adds '/home/jane/fanypdcollection/' to the paths in Pd's
> preferences. Then she installs iemnet to
> /home/jane/fancypdcollection/iemnet after she configured Deken to
> install libraries to /home/jane/fanypdcollection/. Then she creates a
> new patch, therein a [declare -path iemnet] and a [tcpclient] and the
> latter creates successfully.
> 
> Is this the idea?


Yup, with the PR. I'd suggest making a custom build with it and testing 
(please).

Additionally, if iemnet is located in the same folder as the opening patch, it 
would be chosen first over the global location. Also, you can specifically 
*ignore* searching beyond the local scope by adding a ./ in the front of the 
path. :)


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Antoine Rousseau]

>
> Is this the idea?
>
> I think so; anyway, I personally agree with this.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Alexandre Torres Porres]

2018-06-14 15:35 GMT-03:00 Roman Haefeli :

>
> Is this the idea?
>

Yes! And it's working like that in my tests.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Roman Haefeli]

On Thu, 2018-06-14 at 14:18 -0300, Alexandre Torres Porres wrote:
> > Now, I'm going to load mylib with [declare -{std}path mylib] in my
> > patch which fails. What am I missing here?
> 
> Yes, there's the declare issue we know and are addressing, but I'd
> also like to highlight that Deken also asks if you want to add what
> you downloaded to the search path. This intentionally provided a
> working solution to this issue at the time of the release, making it
> all just work by clicking "yes" to stuff, which is quite fine for
> newcomers.  

OK. Just to be sure we are on the same page, I understand that the
following assumptions will be true, once the PRs are accepted:

 * The user defines the environment. The user can define in the pre-
   ferences in which paths [declare] looks for libraries.

 * Patches can use [declare] to load libraries, regardless where they
   are installed as long as the install path was added as searchpath
   in the preferences

 * Patches don't need to know anything about the environment.


Example:


User adds '/home/jane/fanypdcollection/' to the paths in Pd's
preferences. Then she installs iemnet to
/home/jane/fancypdcollection/iemnet after she configured Deken to
install libraries to /home/jane/fanypdcollection/. Then she creates a
new patch, therein a [declare -path iemnet] and a [tcpclient] and the
latter creates successfully.

Is this the idea?

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Alexandre Torres Porres]

2018-06-14 4:52 GMT-03:00 Roman Haefeli :
>
> Does Pd now look into extra's subfolders?


If I got it right, the deal is that Pd always searches in "extra" (but not
subfolders), so if you have a bunch of things in "extra", the thing is
they're always in the search way, so it can be a good idea to keep it as
clear as possible.

My beef with it is that - the way it is presented to me -  it suggests to
> do things that create confusion later.  As a new user: "Do you want to
> create ~/Documents/Pd"?
>
> Yes
>
> "Do you want to add it to the searchpaths?"
>
> Yes
>

It's just one question, the first one, but it does add it to the search
path as well.


> When downloading stuff with deken: "Do you want to install 'mylib' to
> ~/Documents/Pd?"
>
> Yes
>
> Now, I'm going to load mylib with [declare -{std}path mylib] in my patch
> which fails. What am I missing here?
>

Yes, there's the declare issue we know and are addressing, but I'd also
like to highlight that Deken also asks if you want to add what you
downloaded to the search path. This intentionally provided a working
solution to this issue at the time of the release, making it all just work
by clicking "yes" to stuff, which is quite fine for newcomers.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Dan Wilcox]

> On Jun 14, 2018, at 10:21 AM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Roman Haefeli mailto:reduz...@gmail.com>>
> To: Pd-List mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] standard paths for externals
> Message-ID: <0b50bb13c24e850d65000e980526f8234a138f61.ca...@gmail.com 
> <mailto:0b50bb13c24e850d65000e980526f8234a138f61.ca...@gmail.com>>
> Content-Type: text/plain; charset="utf-8"
> 
> Hey Dan
> 
> Thanks for trying to explain.
> 
> On Thu, 2018-06-14 at 01:18 +0200, Dan Wilcox wrote:
>> There seems to be a bit of FUD in this "discussion."
> 
> Maybe things aren't that bad as they were presented. For my part, I
> lost track of who favors what kind of design.
> 
>> Some things from my perspective:
>> 
>> 1. Pd's library/path mechanism is largely oriented toward *local*
>> libs first and *global* ones later, ie. download externals to
>> individual project (sub)folders.
> 
> Pd already used to work like that for quite a while, no?
> 
>> I believe the centralized loading was added later on in Pd-extended. 
> 
> I don't understand what you mean by that. Pd-extended already pre-
> loaded a subset of the installed externals (do you mean this?), which -
> imho - was a bad design choice. It meant there was one person deciding
> what comes pre-loaded and what not.

Yes and continuing that mechanism by installing things into more "standard 
places" is perhaps less ideal, even if it is easy, ie. ~/Library/Pd.

>> If we follow the "programming language model", this might be similar
>> to installing a Python egg locally or globally. I don't see how
>> supporting both modes of working is a problem.
> 
> Me neither.
> 
>> 2. IOhannes convinced me, over time, that the "stdpath" loading
>> mechanism used by the "extra" folder is problematic as it adds too
>> many (sub) search paths by default and it becomes harder to
>> tell/control what's being loaded.
> 
> Forgive my ignorance, but I don't understand. Does Pd now look into
> extra's subfolders? Currently I still have to actively load stuff with
> [declare -stdlib] or [declare -stdpath]. 

It always has, that's one of the "standard paths" aka those that [decalre's 
-stdpath] uses. These are different from the "user search paths" which are 
those  specified in the Path dialog and/or via [declare -path]. Similarly, 
[declare -stdlib] search for lib names *only* in the "standard paths" while 
[decalre -lib] looks only in supplied "user search paths". This is where great 
confusion comes and arguments over what is a path and how things should/can be 
searched.

Our utltimate solution is to move to dis-favor the separation and simply have 
[declare -path] and [dlecare -lib] search both the "standard paths" and the 
"user search paths", first locally, then the "suer paths", and finally the more 
global "standard paths".

>> The "better way" is for people to specify those externals paths
>> directly, either with the user search paths and/or declare.
>> There is much less ambiguity as to what's going on at the loss of
>> "just put things in this place" ease.
> 
> So paths added by the users will be searched by deken? So  instead of
> specifying paths to the library root - as we currently do it - adding a
> path in the future means adding a searchpath that is container for many
> libraries? And deken will find libraries inside the newly added
> searchpath root? 

By deken, do you mean [declare]?

Deken is unrelated to path searching, all it does is download things to a 
place, either the ~/Documents/Pd/externals directory or some other places 
specified by you.



> 
>> 3. As suggested by Alexandre, I wrote a PR to help address how
>> declare search when using -path & -lib by having them search along
>> user search paths as well: https://github.com/pure-data/pure- 
>> <https://github.com/pure-data/pure->
>> data/pull/205. I feel this is a much closer method of using declare
>> to how other programming languages handle such things, ie. Lua's
>> require.
> 
> OK, I hopefully understand now. Am I right in thinking that declare's
> -stdlib, -stdpath flags are considered superfluous because -lib and
> -path will scan all searchpaths in a local -> global order, including
> the parent patch's folder?

That's the general idea. As I mention before, it's hard to tell which to use 
since people tend to put things in different places and, as you mention in a 
previous email, where is the "right" place to put th

Re: [PD] standard paths for externals

[Christof Ressi]

> > 4. The Pd Documents path (aka ~/Documents/Pd) is simply a helper
> > location for beginners. It is only a regular user search path
> > added by default (when desired) and does not search subfolders. 
> 
> Now you challenge my understanding of the term searchpath again. I
> thought the new idea is that you will be able to load libraries with
> [declare] from user-added searchpaths? What's the point of creating
> that folder then? 

because Pd didn't create any folder by default for installing libraries (unlike 
most other programs). rather than creating the folder in one of those awkward 
user paths (btw, in Windows it's something like 
C:\Users\Christof\AppData\Roaming\Pd - of course it's hidden), we offer the 
user a folder they can easily access, following the Arduino model.

> Yes
> 
> Now, I'm going to load mylib with [declare -{std}path mylib] in my
> patch which fails.
> 
> What am I missing here?

because right now [declare] doesn't work with user specified paths (yet). Dan's 
PR attempts to fix this.


> Gesendet: Donnerstag, 14. Juni 2018 um 09:52 Uhr
> Von: "Roman Haefeli" 
> An: Pd-List 
> Betreff: Re: [PD] standard paths for externals
>
> Hey Dan
> 
> Thanks for trying to explain.
> 
> On Thu, 2018-06-14 at 01:18 +0200, Dan Wilcox wrote:
> > There seems to be a bit of FUD in this "discussion."
> 
> Maybe things aren't that bad as they were presented. For my part, I
> lost track of who favors what kind of design.
> 
> > Some things from my perspective:
> > 
> > 1. Pd's library/path mechanism is largely oriented toward *local*
> > libs first and *global* ones later, ie. download externals to
> > individual project (sub)folders.
> 
> Pd already used to work like that for quite a while, no?
> 
> > I believe the centralized loading was added later on in Pd-extended. 
> 
> I don't understand what you mean by that. Pd-extended already pre-
> loaded a subset of the installed externals (do you mean this?), which -
> imho - was a bad design choice. It meant there was one person deciding
> what comes pre-loaded and what not.
> 
> > If we follow the "programming language model", this might be similar
> > to installing a Python egg locally or globally. I don't see how
> > supporting both modes of working is a problem.
> 
> Me neither.
> 
> > 2. IOhannes convinced me, over time, that the "stdpath" loading
> > mechanism used by the "extra" folder is problematic as it adds too
> > many (sub) search paths by default and it becomes harder to
> > tell/control what's being loaded.
> 
> Forgive my ignorance, but I don't understand. Does Pd now look into
> extra's subfolders? Currently I still have to actively load stuff with
> [declare -stdlib] or [declare -stdpath]. 
> 
> >  The "better way" is for people to specify those externals paths
> > directly, either with the user search paths and/or declare.
> >  There is much less ambiguity as to what's going on at the loss of
> > "just put things in this place" ease.
> 
> So paths added by the users will be searched by deken? So  instead of
> specifying paths to the library root - as we currently do it - adding a
> path in the future means adding a searchpath that is container for many
> libraries? And deken will find libraries inside the newly added
> searchpath root? 
> 
> > 3. As suggested by Alexandre, I wrote a PR to help address how
> > declare search when using -path & -lib by having them search along
> > user search paths as well: https://github.com/pure-data/pure-
> > data/pull/205. I feel this is a much closer method of using declare
> > to how other programming languages handle such things, ie. Lua's
> > require.
> 
> OK, I hopefully understand now. Am I right in thinking that declare's
> -stdlib, -stdpath flags are considered superfluous because -lib and
> -path will scan all searchpaths in a local -> global order, including
> the parent patch's folder?
> 
> > 4. The Pd Documents path (aka ~/Documents/Pd) is simply a helper
> > location for beginners. It is only a regular user search path
> > added by default (when desired) and does not search subfolders. 
> 
> Now you challenge my understanding of the term searchpath again. I
> thought the new idea is that you will be able to load libraries with
> [declare] from user-added searchpaths? What's the point of creating
> that folder then? 
> 
> > Nobody has to use it and it can be disabled at any time.
> 
> My beef with it is that - the way it is presented to me 

Re: [PD] standard paths for externals

[Roman Haefeli]

Hey Dan

Thanks for trying to explain.

On Thu, 2018-06-14 at 01:18 +0200, Dan Wilcox wrote:
> There seems to be a bit of FUD in this "discussion."

Maybe things aren't that bad as they were presented. For my part, I
lost track of who favors what kind of design.

> Some things from my perspective:
> 
> 1. Pd's library/path mechanism is largely oriented toward *local*
> libs first and *global* ones later, ie. download externals to
> individual project (sub)folders.

Pd already used to work like that for quite a while, no?

> I believe the centralized loading was added later on in Pd-extended. 

I don't understand what you mean by that. Pd-extended already pre-
loaded a subset of the installed externals (do you mean this?), which -
imho - was a bad design choice. It meant there was one person deciding
what comes pre-loaded and what not.

> If we follow the "programming language model", this might be similar
> to installing a Python egg locally or globally. I don't see how
> supporting both modes of working is a problem.

Me neither.

> 2. IOhannes convinced me, over time, that the "stdpath" loading
> mechanism used by the "extra" folder is problematic as it adds too
> many (sub) search paths by default and it becomes harder to
> tell/control what's being loaded.

Forgive my ignorance, but I don't understand. Does Pd now look into
extra's subfolders? Currently I still have to actively load stuff with
[declare -stdlib] or [declare -stdpath]. 

>  The "better way" is for people to specify those externals paths
> directly, either with the user search paths and/or declare.
>  There is much less ambiguity as to what's going on at the loss of
> "just put things in this place" ease.

So paths added by the users will be searched by deken? So  instead of
specifying paths to the library root - as we currently do it - adding a
path in the future means adding a searchpath that is container for many
libraries? And deken will find libraries inside the newly added
searchpath root? 

> 3. As suggested by Alexandre, I wrote a PR to help address how
> declare search when using -path & -lib by having them search along
> user search paths as well: https://github.com/pure-data/pure-
> data/pull/205. I feel this is a much closer method of using declare
> to how other programming languages handle such things, ie. Lua's
> require.

OK, I hopefully understand now. Am I right in thinking that declare's
-stdlib, -stdpath flags are considered superfluous because -lib and
-path will scan all searchpaths in a local -> global order, including
the parent patch's folder?

> 4. The Pd Documents path (aka ~/Documents/Pd) is simply a helper
> location for beginners. It is only a regular user search path
> added by default (when desired) and does not search subfolders. 

Now you challenge my understanding of the term searchpath again. I
thought the new idea is that you will be able to load libraries with
[declare] from user-added searchpaths? What's the point of creating
that folder then? 

> Nobody has to use it and it can be disabled at any time.

My beef with it is that - the way it is presented to me -  it suggests
to do things that create confusion later. 

As a new user:

"Do you want to create ~/Documents/Pd"

Yes

"Do you want to add it to the searchpaths?"

Yes

When downloading stuff with deken: "Do you want to install 'mylib' to
~/Documents/Pd?"

Yes

Now, I'm going to load mylib with [declare -{std}path mylib] in my
patch which fails.

What am I missing here?


> 5. Yes, the macOS hiding the ~/Library folder is problematic for many
> users as they don't know how to show it and are afraid to modify
> things within it. I've recently taught classes to beginners that are
> just learn gin the concept of a "file system" as they grew up mainly
> using "mobile phones"

I don't see how deken requires users to have a notion about a
filesystem. Ideally, I'd use deken to tell _what_ I want to install.
Ideally, I'd tell my patch through [declare] _what_ to load. All the
_where_ stuff shouldn't be a question neither at installing nor loading
time. The _where_ stuff should only matter when the user tweaks their
environment: "I'd rather put my 4.5 TB of Pd externals on my external
drive ". 

>  ... Plus, ~/Library/Pd was also a "kitchen sink" std path with the
> issues listed in #2.
> 
> 6. I've attempted to provide some solutions to various issues
> outlined over the last year regarding [declare] and folders. It would
> be helpful to get more feedback earlier on in testing /
> experimentation, rather well after a release. 

Valid and important point. I will try to the get a more clear picture
from the actual implementation instead of a messy Pd list thread.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Alexandre Torres Porres]

2018-06-13 20:18 GMT-03:00 Dan Wilcox :

> 2. IOhannes convinced me, over time, that the "stdpath" loading mechanism
> used by the "extra" folder is problematic as it adds too many (sub) search
> paths by default and it becomes harder to tell/control what's being loaded.
>

hmm, I see...


> The "better way" is for people to specify those externals paths directly,
> either with the user search paths and/or declare. There is much less
> ambiguity as to what's going on at the loss of "just put things in this
> place" ease.
>

But now we have a folder like ~/Documents/Pd that Pd suggests you to use,
and then it creates it for you, and also creates ~/Documents/Pd/externals,
and Deken puts thins in there for you... So, where I'm getting at is that this
new process provides exactly that "*just put things in this place*" kind of
ease, and therefore *no* loss - plus, we also have less ambiguity and avoid
a problematic Ioading mechanism. In short, looks like a "win-win"
situation...

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Dan Wilcox]

There seems to be a bit of FUD in this "discussion."

Some things from my perspective:

1. Pd's library/path mechanism is largely oriented toward *local* libs first 
and *global* ones later, ie. download externals to individual project 
(sub)folders. I believe the centralized loading was added later on in 
Pd-extended. If we follow the "programming language model", this might be 
similar to installing a Python egg locally or globally. I don't see how 
supporting both modes of working is a problem.

2. IOhannes convinced me, over time, that the "stdpath" loading mechanism used 
by the "extra" folder is problematic as it adds too many (sub) search paths by 
default and it becomes harder to tell/control what's being loaded. The "better 
way" is for people to specify those externals paths directly, either with the 
user search paths and/or declare. There is much less ambiguity as to what's 
going on at the loss of "just put things in this place" ease.

3. As suggested by Alexandre, I wrote a PR to help address how declare search 
when using -path & -lib by having them search along user search paths as well: 
https://github.com/pure-data/pure-data/pull/205 
. I feel this is a much closer 
method of using declare to how other programming languages handle such things, 
ie. Lua's require.

4. The Pd Documents path (aka ~/Documents/Pd) is simply a helper location for 
beginners. It is only a regular user search path added by default (when 
desired) and does not search subfolders. Nobody has to use it and it can be 
disabled at any time.

5. Yes, the macOS hiding the ~/Library folder is problematic for many users as 
they don't know how to show it and are afraid to modify things within it. I've 
recently taught classes to beginners that are just learn gin the concept of a 
"file system" as they grew up mainly using "mobile phones" ... Plus, 
~/Library/Pd was also a "kitchen sink" std path with the issues listed in #2.

6. I've attempted to provide some solutions to various issues outlined over the 
last year regarding [declare] and folders. It would be helpful to get more 
feedback earlier on in testing / experimentation, rather well after a release. 
OTOH if I attempted to do work for free on Pd that pleased *everyone*, I 
suppose I wouldn't bother.

(7. Code talks.)


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Alexandre Torres Porres]

2018-06-13 14:20 GMT-03:00 Christof Ressi :

> basically, I agree with Alexandre. To sum it up quickly from my point of
> view:
>
> 1) "-path" in [declare] should apply to *all* paths - including the user
> defined paths.
> 2) "-stdpath" and "-stdlib" should be deprecated and just become aliases
> to "-path" and "-lib"
>

Well, I mentioned about a pull request that was fixing [declare]. Here it
is: https://github.com/pure-data/pure-data/pull/205

And in fact it does all of that you just asked for. If I use [declare -path
else] I can get it to search for the else folder inside "extra". By the
way, it is already working like that for [declare -lib]. Check it out
yourself if you haven't.

this way we would have a unified way of dealing with paths which would be
> less confusing. does anyone see possible issues with that?
>

I don't think anyone has searched for more issues than me when this new way
of handling externals was proposed by Dan. I was very conservative! But
then Miller said we could just get the path mechanism and [declare] to
behave as people wanted, and I couldn't really find any issue with that.

Of course we still needed to do stuff in order for that to happen. But this
fix for [declare] was actually the only thing I found in the way of the new
process. I just couldn't find anything else...

And responding to your question, I can't see any issue with the fix from
the Pull Request. It has no backwards compatibility issues, it makes
perfect sense, it simplify things dramatically and it integrates pretty
well with the new process for Pd.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Christof Ressi]

basically, I agree with Alexandre. To sum it up quickly from my point of view:

 

1) "-path" in [declare] should apply to *all* paths - including the user defined paths.

2) "-stdpath" and "-stdlib" should be deprecated and just become aliases to "-path" and "-lib"

 

this way we would have a unified way of dealing with paths which would be less confusing. does anyone see possible issues with that?

 

Christof

 

Gesendet: Mittwoch, 13. Juni 2018 um 17:13 Uhr
Von: "Alexandre Torres Porres" 
An: "Roman Haefeli" 
Cc: Pd-List 
Betreff: Re: [PD] standard paths for externals


 
 
2018-06-13 4:18 GMT-03:00 Roman Haefeli <reduz...@gmail.com>:


I seem to disagree in almost everything you say.

 

I didnt say anything, I'm quoting someone else...

 

Your proposal has two - imho: major - drawbacks.

 

It's not my proposal, I'm not proposing anything...

 

By putting libraries
anywhere (outside any searchpath) and loading them per preferences, you
loose the ability to 'activate' libraries on the fly from the patch
with [declare]

 

Like I said, there is a Pull Request that already fixes this. And I'm the one who reported that issue, by the way, so I know about it.

 

I don't see a good reason to proactively work against this as you seem to
do.

 

again, this is not me, not my proposal, so I'm not doing anything...

 

In my understanding, the user should just know what libraries to
download and the rest is done by the patch by using the right
[declare}s. Also, by preventing [declare] from working - as you propose

 

It's funny how you keep putting this on my bill as my proposal. I dont know where you got the idea Im proposing that... all I said is that things are going this way now, and there might still be issues as with declare, but it'll be fixed in the next release. This is not a matter of opinion, not a proposal, just reporting facts here.

 

> > there's a deep rift between the factions.
>
> Ok, I don't know about that

Now you know.

 

All I know is that you're reporting a bug that has a Pull request that already fixes it. And by the way, it already works like that if you want to load libraries like cyclone, zexy, Gem. The issue is only with adding a path to declare. I, for one, just do not use [declare], and can live pretty well without it, really.

Deken has made it painless to download and add a path for you. I get it if you like [declare] and want to use it so maybe don't do this way right now. But you can live without it if you wanted. There are ways to manage dependencies and everything. All this argument seem to imply [declare] is the only possible mechanism to deal with importing libraries. It is not.

 

By 'new way' you mean that libraries should be installed anywhere and
added to the preferences?

 

yes, add it to the path, that is what Miller said in that message and all discussions prior to 0.48 went in this direction where we don't want people to install libraries to "Standard Paths", just into user added paths. Again, for the 1000th time, that wasn't my proposal, I actually argued against it, using the very same argument that [declare] wouldn't work well, but the idea is now to just fix that...

 

So yeah, I'm now cool with it...

 

It appears to me that you created this mess by requesting that  ~/Library/Pd should be replaced by ~/Documents/Pd (in macOS, at least).



I don't have the power to change Pd. And I didn't create any "mess" because I didn't propose a change to not use "standard paths" as you didn't like.

 

Yes, I proposed a new standard path change, but the outcome was that Miller and Dan felt users shouldn't use "standard paths", like I said before.

 


I couldn't care less about macOS, but in my opinion the fact that you need to hit Shift-Cmd-G to
graphically visit this folder doesn't warrant this change in Pd.

 

That is not what happened. Pd didn't change because of Apple... at all. 

 

Why does the user need to check that folder anyway, since
Deken already manages it quite well?

 

It actually doesn't, you still need to access folders to do simple things like removing an older version of a library before installing a new one. But again, you're not getting the real issue. None of this came up because of apple, or because deken is not perfect yet. It is only a matter of not wanting people to install libraries in "Standard Path" in the first and only place. Don't try to find other reason that that. That is it.

 

If you have an issue with that besides the bug that is already being fixed. Please bring it to the table.

 

sorry for saying it directly - which you are at least partially responsible for.

 

wow, I didn't realize when you mentioned a million times bef

Re: [PD] standard paths for externals

[Alexandre Torres Porres]

2018-06-13 4:18 GMT-03:00 Roman Haefeli :

>
> I seem to disagree in almost everything you say.
>

I didnt say anything, I'm quoting someone else...


> Your proposal has two - imho: major - drawbacks.


It's not my proposal, I'm not proposing anything...


> By putting libraries
> anywhere (outside any searchpath) and loading them per preferences, you
> loose the ability to 'activate' libraries on the fly from the patch
> with [declare]


Like I said, there is a Pull Request that already fixes this. And I'm the
one who reported that issue, by the way, so I know about it.


> I don't see a good reason to proactively work against this as you seem to
> do.


again, this is not me, not my proposal, so I'm not doing anything...


> In my understanding, the user should just know what libraries to
> download and the rest is done by the patch by using the right
> [declare}s. Also, by preventing [declare] from working - as you propose
>

It's funny how you keep putting this on my bill as my proposal. I dont know
where you got the idea Im proposing that... all I said is that things are
going this way now, and there might still be issues as with declare, but
it'll be fixed in the next release. This is not a matter of opinion, not a
proposal, just reporting facts here.


> > > there's a deep rift between the factions.
> >
> > Ok, I don't know about that
>
> Now you know.
>

All I know is that you're reporting a bug that has a Pull request that
already fixes it. And by the way, it already works like that if you want to
load libraries like cyclone, zexy, Gem. The issue is only with adding a
path to declare. I, for one, just do not use [declare], and can live pretty
well without it, really.

Deken has made it painless to download and add a path for you. I get it if
you like [declare] and want to use it so maybe don't do this way right now.
But you can live without it if you wanted. There are ways to manage
dependencies and everything. All this argument seem to imply [declare] is
the only possible mechanism to deal with importing libraries. It is not.


> By 'new way' you mean that libraries should be installed anywhere and
> added to the preferences?


yes, add it to the path, that is what Miller said in that message and all
discussions prior to 0.48 went in this direction where we don't want people
to install libraries to "Standard Paths", just into user added paths.
Again, for the 1000th time, that wasn't my proposal, I actually argued
against it, using the very same argument that [declare] wouldn't work well,
but the idea is now to just fix that...

So yeah, I'm now cool with it...


> It appears to me that you created this mess by requesting that
> ~/Library/Pd should be replaced by ~/Documents/Pd (in macOS, at least).


I don't have the power to change Pd. And I didn't create any "mess" because
I didn't propose a change to not use "standard paths" as you didn't like.

Yes, I proposed a new standard path change, but the outcome was that Miller
and Dan felt users shouldn't use "standard paths", like I said before.


> I couldn't care less about macOS, but in my opinion the fact that you need
> to hit Shift-Cmd-G to
> graphically visit this folder doesn't warrant this change in Pd.


That is not what happened. Pd didn't change because of Apple... at all.

Why does the user need to check that folder anyway, since
> Deken already manages it quite well?


It actually doesn't, you still need to access folders to do simple things
like removing an older version of a library before installing a new one.
But again, you're not getting the real issue. None of this came up because
of apple, or because deken is not perfect yet. It is only a matter of not
wanting people to install libraries in "Standard Path" in the first and
only place. Don't try to find other reason that that. That is it.

If you have an issue with that besides the bug that is already being fixed.
Please bring it to the table.

sorry for saying it directly - which you are at least partially responsible
> for.
>

wow, I didn't realize when you mentioned a million times before I had
responsibility for this :) thanks for being direct.

I hope you realize though I had zero responsibility (not even partial) as.
I never proposed any of this and, in fact, like I said in the first
message, I had opposed myself.

Sorry to repeat myself over and over. But it seems it was necessary to make
a point I'm not your target.

Cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Roman Haefeli]

On Tue, 2018-06-12 at 16:16 -0300, Alexandre Torres Porres wrote:

> Well, there has definitely been results in the design of Pd that came
> out of recent discussions. Let me point again to what Miller said in 
> https://lists.puredata.info/pipermail/pd-list/2017-07/119839.html to
> highlight the notion that we should not use "Standard Path" to
> install externals, and this is regardless if there is one or more of
> them, and if there should be only one... it doesn't matter, just
> don't use them. 

I seem to disagree in almost everything you say.

I tell people to do exactly the opposite of what you're telling them.
Your proposal has two - imho: major - drawbacks. By putting libraries
anywhere (outside any searchpath) and loading them per preferences, you
loose the ability to 'activate' libraries on the fly from the patch
with [declare] since they are already loaded anyway.  By doing it this
way, you require the user to modify their environment in order for them
to run a certain patch. In my understanding of programming
environments, the software imports/declares its own dependencies. The
dependencies need to be installed, but the actual loading happens from
within the software. I guess that is common quite common practice. I
don't see a good reason to proactively work against this as you seem to
do. In my understanding, the user should just know what libraries to
download and the rest is done by the patch by using the right
[declare}s. Also, by preventing [declare] from working - as you propose
- how is a patch dev supposed to document the patch's dependencies?
What you suggest just simply doesn't add up for me.  


> As Miller said in that message, we should just use the "Path"
> mechanism, and no Standard Paths. This means just have your externals
> anywhere and put them in "Preferences => Path" if you want them to be
> automatically loaded. Now, this may not yet be 100% fully well
> integrated with Pd, I don't know what IOhannes meant by that, but I
> can say that if you want to use [declare] instead of doing this, it
> won't work well, but there's already a Pull Request that fixes it. So
> whatever is not perfect yet with the new system should be fixed soon.
>  
> > there's a deep rift between the factions.
> 
> Ok, I don't know about that

Now you know. 

>  and I haven't seen one. By the way, let me just make it clear that I
> do not have a dog in this fight, I'm just going with the flow without
> disputing anything. Yeah, I actually first opposed to the new way of
> doing things since 0.48, 

By 'new way' you mean that libraries should be installed anywhere and
added to the preferences? It appears to me that you created this mess
by requesting that  ~/Library/Pd should be replaced by ~/Documents/Pd
(in macOS, at least). Now, Deken asks to create this folder that is of
no practical use. This proposal probably got triggered by the fact that
Apple decided to hide ~/Library from Finder. I couldn't care less about
macOS  , but in my opinion the fact that you need to hit Shift-Cmd-G to
graphically visit this folder doesn't warrant this change in Pd. Yeah,
it was stupid move by Apple, but shouldn't every macOS user know how to
visit invisible folders anyway? Does the Pd community have to care
about that? Why does the user need to check that folder anyway, since
Deken already manages it quite well? Now there is a new folder which is
not a standard path and just creates mess and confusion and pages long
discussions in github issues and - sorry for saying it directly - which
 you are at least partially responsible for. 

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Alexandre Torres Porres]

2018-06-12 8:00 GMT-03:00 IOhannes m zmoelnig :

>
> why do you think it is outdated?
>

I think cause it doesn't say about the new way of doing things since 0.48.


> everything you found on the how-do-i-install-exernals-and-help-files FAQ
> is correct.
>

Well, recent discussions seem to have at least challenged this entry.
Specially Miller and Dan felt it wasn't the right approach or the way to do
things.

The FAQ basically describes three different "Standard Paths" (paths
automatically searched for things) for Pd. They are the app specific
("extra" folder), local and global path. Although Pd has these 3 locations
hard coded as "Standard Paths", there seems to be a conflict/inconsistency
in what "Standard Path" is or should be, and that the local and global path
shouldn't really exist. I say that because:

*A)* Pure Data, up to this day, does come with or create the local/global
folder, so the user has to go for it.
*B)* The local/global folder are never mentioned in Pd Vanilla's
documentation. And in fact, only the "extra" folder is described as a
"Standard Path" in Pd Vanilla's manual, and  - see
http://msp.ucsd.edu/Pd_documentation/x3.htm#s5 for reference
*C)* Miller stated that "Standard Path" was always meant to refer to what
comes with Pd - that is, of course, things in the "extra" folder, and not
the other folders which don't come with Pd (see "A") and are not even
documented (see "B"). Here's the reference:
https://lists.puredata.info/pipermail/pd-list/2017-07/119839.html

Now, regarding "A)", I know Pd Extended did create at least the "local"
folder, for macOS. So this seems to have been something well integrated in
Pd Extended. Hence, I wonder if these two other paths (local/global) got
into Vanilla from Extended's influence without Miller noticing it - as it'd
explain them not being documented in Pd's manual, not being provided by the
software and Miller stating he never meant those folders to be "Standard
Paths". Perhaps someone here can tell me more about how this got into Pd.

But that is a parallel discussion. What's more relevant is that, influenced
by this FAQ entry, I proposed a different/better folder for macOS. Well, to
my surprise, all this idea I got about that FAQ entry being the canonical
way of doing things just fell apart, and Miller/Dan went for another
approach that kinda ignores this FAQ entry, which is the new way since 0,48
(here's a long discussion for reference
https://github.com/pure-data/pure-data/pull/139).

> There has been discussions about this frequently, but I can't seem to
> > find the results of it. Was there something which was agreed upon?


Well, there has definitely been results in the design of Pd that came out
of recent discussions. Let me point again to what Miller said in
https://lists.puredata.info/pipermail/pd-list/2017-07/119839.html to
highlight the notion that we should not use "Standard Path" to install
externals, and this is regardless if there is one or more of them, and if
there should be only one... it doesn't matter, just don't use them.

As Miller said in that message, we should just use the "Path" mechanism,
and no Standard Paths. This means just have your externals anywhere and put
them in "Preferences => Path" if you want them to be automatically loaded.
Now, this may not yet be 100% fully well integrated with Pd, I don't know
what IOhannes meant by that, but I can say that if you want to use
[declare] instead of doing this, it won't work well, but there's already a
Pull Request that fixes it. So whatever is not perfect yet with the new
system should be fixed soon.


> there's a deep rift between the factions.


Ok, I don't know about that, and I haven't seen one. By the way, let me
just make it clear that I do not have a dog in this fight, I'm just going
with the flow without disputing anything. Yeah, I actually first opposed to
the new way of doing things since 0.48, as I was influenced by that FAQ
entry and worried about a good integration to Pd's mechanism, so I argued
on it. But once things went the way they did, I'm embracing it and thought
that was the new consensus. And speaking as someone that had lots of
resistance to the new approach in the beginning, I don't see any real
issues now. If you or anyone else have issues, let's put them on the table
and work on them.

One way or another, I just hope that aren't rifts and that such challenging
notions get sorted out. I say that because I want to write a new
documentation on how to install externals nowadays, and there still seems
to be lots of confusion in the air, which gets in the way of writing a
clear documentation, and prevents the development of a text that would make
things more objective and clear to everyone. This thread is a very good
example on how even advanced users are still confused about all this, so we
should do something about it. I think it's very important. If advanced
users are confused, imagine newcomers...

cheers
__

Re: [PD] standard paths for externals

[IOhannes m zmoelnig]

On 2018-06-12 12:10, Max wrote:
> I'm looking for the canonical paths to install externals for the
> different platforms and only can find information which seems to be
> outdated, like here:
> 
> http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files

why do you think it is outdated?

> At least deken seems to install into ~/Documents/Pd/externals instead.
no. that's only half-true.
deken uses a configured install path or - as a fallback - the first
available (and writable) sys_search path.
when *you* clicked on "yes, please create a ~/Documents/Pd/ folder for
me where i want to put all the externals into" at the "first" startup of
Pd, you implicitely created ~/Documents/Pd/externals/ and added it to
deken's install path.

however, apart from this (missing) new-fangled path which seems to not
integrate that well with Pd's search in the first place, everything you
found on the how-do-i-install-exernals-and-help-files FAQ is correct.

> There has been discussions about this frequently, but I can't seem to
> find the results of it. Was there something which was agreed upon?

nothing.
there's a deep rift between the factions.

> 
> For which paths should an installer (ore make install) of an external
> look for?

in general i tend to use the pd-lib-builder Makefile as a reference for
such things any such things (it's a bit less conservative than myself,
without falling for each and every bel-de-jour).

btw, you should really consider using pd-lib-builder Makefile as the
buildsystem for all externals.

fgasdrmn
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] standard paths for externals

[Max]

I'm looking for the canonical paths to install externals for the 
different platforms and only can find information which seems to be 
outdated, like here:


http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files

At least deken seems to install into ~/Documents/Pd/externals instead.

There has been discussions about this frequently, but I can't seem to 
find the results of it. Was there something which was agreed upon?


For which paths should an installer (ore make install) of an external 
look for?


Thanks

m.


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list