On 2013-01-31 22:18:46 +, Stéphane Klein said:
Hi,
I try to use pyScss with buildout but not success :
$ cat buildout.cfg
[buildout]
parts = pyscss
[pyscss]
recipe = z3c.recipe.scripts
eggs =
pyScss
$ python bootstrap.py
$ bin/buildout
$ ls bin
buildout pyscss
$ bin/pyscss
Traceback
Hi,
I try to use pyScss with buildout but not success :
$ cat buildout.cfg
[buildout]
parts = pyscss
[pyscss]
recipe = z3c.recipe.scripts
eggs =
pyScss
$ python bootstrap.py
$ bin/buildout
$ ls bin
buildout pyscss
$ bin/pyscss
Traceback (most recent call last):
File "bin/pyscss", line 20
On Thursday, January 31, 2013 at 9:10 AM, Nick Coghlan wrote:
> So, here's my suggestion for a way forward:
>
> 1. PEP 426 incorporates the "new versioning algorithm" section from
> PEP 386 directly rather than by reference, with the clarification that
> a top level "dev" release should be sorted
On Thu, Jan 31, 2013 at 03:37:21PM +0100, Stéphane Klein wrote:
> I wonder what is the best practice to clean a buildout project ?
>
> I would like a command to remove :
>
> * bin/
> * develop-eggs
> * parts
> * .installed.cfg
>
> I can create a Makefile clean, or clean.sh script.
>
> What do y
Here's the wheel pep itself again. I think the prose is precise enough but
it could be more clear. My goal is to get these PEPs accepted so the pip
maintainers will be willing to merge the waiting "pip can install wheel"
branch. It's not perfect, it's extensible.
PEP: 427
Title: The Wheel Binary
Here's a re-post of PEP 425 "Compatibility Tags for Build Distributions".
It belongs to the wheel suite of PEPs: 425 (compatibility tags), 426
(metadata) and 427 (wheel).
PEP: 425
Title: Compatibility Tags for Built Distributions
Version: $Revision$
Last-Modified: 07-Aug-2012
Author: Daniel Holth
On Thu, Jan 31, 2013 at 9:10 AM, Nick Coghlan wrote:
> On Thu, Jan 31, 2013 at 9:39 PM, Donald Stufft
> wrote:
> > On Thursday, January 31, 2013 at 1:20 AM, Nick Coghlan wrote:
> >
> >
> > Correct. The desire is still to migrate to a more formal versioning
> > scheme, hence PEP 386 by default if
On Thu, Jan 31, 2013 at 2:37 PM, Stéphane Klein
wrote:
> Hi,
>
> I wonder what is the best practice to clean a buildout project ?
I don't think I have ever used a "clean" command for a buildout project.
What do you want it for?
> What do you do in your project ?
The few times I have wanted a cl
On Thu, Jan 31, 2013 at 3:37 PM, Stéphane Klein
wrote:
> Hi,
> I wonder what is the best practice to clean a buildout project ?
> I would like a command to remove :
> * bin/
> * develop-eggs
> * parts
> * .installed.cfg
> I can create a Makefile clean, or clean.sh script.
> What do you do in your
On 2013-01-31 14:37:21 +, Stéphane Klein said:
Hi,
I wonder what is the best practice to clean a buildout project ?
I would like a command to remove :
* bin/
* develop-eggs
* parts
* .installed.cfg
I can create a Makefile clean, or clean.sh script.
What do you do in your project ?
I
On Thu, Jan 31, 2013 at 3:37 PM, Stéphane Klein
wrote:
> I can create a Makefile clean, or clean.sh script.
>
> What do you do in your project ?
$ git clean -dfx
--
Sebastien Douche
Twitter: @sdouche / G+: +sdouche
___
Distutils-SIG maillist - Dist
Hi,
I wonder what is the best practice to clean a buildout project ?
I would like a command to remove :
* bin/
* develop-eggs
* parts
* .installed.cfg
I can create a Makefile clean, or clean.sh script.
What do you do in your project ?
Best regards,
Stephane
--
Stéphane Klein
blog: http://st
On Thu, Jan 31, 2013 at 9:39 PM, Donald Stufft wrote:
> On Thursday, January 31, 2013 at 1:20 AM, Nick Coghlan wrote:
>
>
> Correct. The desire is still to migrate to a more formal versioning
> scheme, hence PEP 386 by default if no Version-Scheme is specified.
> However, I don't want "but what if
Sounds like a :: and a "If not specified, pep386 should be assumed" are the
only things missing from this PEP.
On Thu, Jan 31, 2013 at 6:39 AM, Donald Stufft wrote:
> On Thursday, January 31, 2013 at 1:20 AM, Nick Coghlan wrote:
>
>
> Correct. The desire is still to migrate to a more formal vers
On Thu, Jan 31, 2013 at 9:42 PM, Alex Clark wrote:
> I think the short answer, as always, is: getting pip into the stdlib would
> require a tremendous amount of work that some would have to want to do[1]
> before it could happen. IIUC, the current direction is something like "get a
> packaging sta
On 2013-01-31 09:05:17 +, Philippe Ombredanne said:
On Wed, Jan 30, 2013 at 9:09 PM, Vinay Sajip wrote:
Python 3.3 includes a script, pyvenv, which is used to create virtual
environments.
However, Distribute and pip are not installed in such environments - because,
though they are popular
On Thursday, January 31, 2013 at 1:20 AM, Nick Coghlan wrote:
>
> Correct. The desire is still to migrate to a more formal versioning
> scheme, hence PEP 386 by default if no Version-Scheme is specified.
> However, I don't want "but what if PEP 386 doesn't handle my
> pre/post/whatever release nam
On Wed, Jan 30, 2013 at 9:09 PM, Vinay Sajip wrote:
> Python 3.3 includes a script, pyvenv, which is used to create virtual
> environments.
> However, Distribute and pip are not installed in such environments - because,
> though they are popular, they are third-party packages - not part of Python
18 matches
Mail list logo
