On Sat, Jan 28, 2017 at 1:00 AM, Jan Alexander Steffens
wrote:
> On Fri, Jan 27, 2017 at 5:56 PM Dave Page wrote:
>>
>> On Fri, Jan 27, 2017 at 1:37 PM, Jan Alexander Steffens
>> wrote:
>> > I did mean Py_SetPath, not PySys_SetPath.
>>
>> Ah, OK - it wouldn't compile with that (Python 2 :-/ ) so
On Fri, Jan 27, 2017 at 5:56 PM Dave Page wrote:
> On Fri, Jan 27, 2017 at 1:37 PM, Jan Alexander Steffens
> wrote:
> > I did mean Py_SetPath, not PySys_SetPath.
>
> Ah, OK - it wouldn't compile with that (Python 2 :-/ ) so I assumed it
> was a typo.
>
> > Unfortunately, after checking
> > again
On Fri, Jan 27, 2017 at 1:37 PM, Jan Alexander Steffens
wrote:
> On Fri, Jan 27, 2017 at 12:04 PM Dave Page wrote:
>>
>> On Thu, Jan 26, 2017 at 7:22 PM, Jan Alexander Steffens
>> wrote:
>> > Looking through the cpython code, Py_SetPath(NULL) clears the calculated
>> > module search path again.
On Fri, Jan 27, 2017 at 12:04 PM Dave Page wrote:
> On Thu, Jan 26, 2017 at 7:22 PM, Jan Alexander Steffens
> wrote:
> > Looking through the cpython code, Py_SetPath(NULL) clears the calculated
> > module search path again. Try calling this before the Py_Initialize.
>
> Unfortunately that just c
On Thu, Jan 26, 2017 at 7:22 PM, Jan Alexander Steffens
wrote:
> On Thu, Jan 26, 2017 at 3:58 PM Dave Page wrote:
>>
>> In the meantime, I'm thinking something like the attached patch would
>> be more appropriate. The only issue I can find with it at the moment
>> (having just tested on a Mac dev
On Thu, Jan 26, 2017 at 3:58 PM Dave Page wrote:
> In the meantime, I'm thinking something like the attached patch would
> be more appropriate. The only issue I can find with it at the moment
> (having just tested on a Mac dev environment for now) is that if
> initialisation fails and you enter a
Hi
On Wed, Jan 25, 2017 at 2:35 PM, Jan Alexander Steffens
wrote:
>
>
> On Wed, Jan 25, 2017 at 2:57 PM Dave Page wrote:
>>
>> One where the virtualenv is in a path that's not related to the
>> location of the runtime. If I'm reading the code correctly, you're
>> taking the appDir (the location
On Wed, Jan 25, 2017 at 2:57 PM Dave Page wrote:
> One where the virtualenv is in a path that's not related to the
> location of the runtime. If I'm reading the code correctly, you're
> taking the appDir (the location of the runtime executable) and
> appending a platform-specific path to the virt
On Wed, Jan 25, 2017 at 12:39 PM Dave Page wrote:
> As far as I can see, this breaks usage in development environments, or
> any configurations where the Python code may be separated from the
> runtime. Am I missing something?
>
What kind of setup are you talking about? It's not clear to me.
If
On Wed, Jan 25, 2017 at 1:43 PM, Jan Alexander Steffens
wrote:
> On Wed, Jan 25, 2017 at 12:39 PM Dave Page wrote:
>>
>> As far as I can see, this breaks usage in development environments, or
>> any configurations where the Python code may be separated from the
>> runtime. Am I missing something?
Hi
On Wed, Jan 25, 2017 at 9:21 AM, Jan Alexander Steffens
wrote:
> Hi,
>
> in the process of packaging pgAdmin4 in Arch Linux I ran into trouble
> getting it to start, which I reduced to a bad sys.path.
>
> The attached patch simplifies the Python initialization. If the program name
> is set to
Hi,
in the process of packaging pgAdmin4 in Arch Linux I ran into trouble
getting it to start, which I reduced to a bad sys.path.
The attached patch simplifies the Python initialization. If the program
name is set to match the venv's interpreter executable, Py_Initialize will
set up sys.path to m
12 matches
Mail list logo
