[issue12394] packaging: generate scripts from callable (dotted paths)

Changes by Éric Araujo : -- resolution: -> out of date stage: needs patch -> committed/rejected status: open -> closed ___ Python tracker ___ ___

[issue12394] packaging: generate scripts from callable (dotted paths)

Changes by Éric Araujo : Removed file: http://bugs.python.org/file23008/7099110c8f14.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue12394] packaging: generate scripts from callable (dotted paths)

Changes by Éric Araujo : Removed file: http://bugs.python.org/file24658/9a7dba6e6f1a.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: Or I won’t, as even a dumb no-git-style diff does not create a review link, maybe because of the binary file change. *Sigh* Trying again. -- Added file: http://bugs.python.org/file24659/9a7dba6e6f1a.diff ___ Python t

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: I merged default yesterday and produced this patch. I’ll use the review site to make comments. -- Added file: http://bugs.python.org/file24658/9a7dba6e6f1a.diff ___ Python tracker

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: @Éric: you may also be interested in a standalone launcher which I wrote for the pythonv branch: https://bitbucket.org/vinay.sajip/simple_launcher/ This is built using Visual Studio and is not based on setuptools code, but uses the same Windows API for child pr

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: I’ll get back to this issue later, but now I just wanted to add a link about building the binary exe files: http://mail.python.org/pipermail/python-dev/2006-April/063846.html (it comes from the time where setuptools was supposed to be added to the stdlib) -

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: To expand on what I said about not seeing how things will work under Windows: are we going to place .exe launchers adjacent to the script, like setuptools does? If the script just has a shebang of "#!/usr/bin/env python", how is the launcher supposed to determin

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: > >> What about Windows support? > Just like with distutils: the file extension is used, not the shebang. Please spell out for me how you see this working: I don't see it. Note that scripts have to use the correct Python even if they are invoked using an expl

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: > What about Windows support? Just like with distutils: the file extension is used, not the shebang. -- ___ Python tracker ___ ___

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: > We’ll have to think about the shebang munging and decide if we keep it.  I > think  > recommending that people use “/usr/bin/env python” (or python3) and not doing > anything to the shebang may be the best thing. What about Windows support? Of course there is

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: > FYI: In pythonv, the build_scripts functionality provides identical support > for dotted > callables to what Éric proposed, while preserving existing functionality for > ordinary script > files. My current preference is to use only new-style generated scripts

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: Re. the launcher changes, those improvements by Guy Rozendorn are welcome. I noticed some differences from the approach taken by Mark Hammond and Curt Hagenlocher in the PEP 397 implementation, which I ported to C: The Ctrl-C is ignored by the PEP 397 launcher.

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: FYI: In pythonv, the build_scripts functionality provides identical support for dotted callables to what Éric proposed, while preserving existing functionality for ordinary script files. Thus: scripts = demo1 demo2 = amodule.main demo3 = apackage.asubpackage

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: FTR, distribute recently committed two fixes for the exe wrappers: https://bitbucket.org/tarek/distribute/issue/238 and https://bitbucket.org/tarek/distribute/issue/207 -- ___ Python tracker

[issue12394] packaging: generate scripts from callable (dotted paths)

Changes by Éric Araujo : Added file: http://bugs.python.org/file23008/7099110c8f14.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: Just to clarify: I'm -1 on heuristics too; it's better to have some way of explicitly declaring the intention. I've no problem with e.g. the [scripts] section being used just for generated scripts, as long as there is a clear way of designating arbitrary .py/.py

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: Heh, I messed up my example: unit2-tk = unittest2.gui.main gui -- ___ Python tracker ___ ___ Python-b

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: > scripts = >foo = a.b.c.main >foowin = a.b.c.winmain -window This is great. About -window: I don’t think using a fake option style (leading -) is useful, and I’d reuse the setuptools name, “gui”. I also think this good idea of yours can solve our oth

[issue12394] packaging: generate scripts from callable (dotted paths)

Changes by Éric Araujo : Removed file: http://bugs.python.org/file22934/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue12394] packaging: generate scripts from callable (dotted paths)

Changes by Éric Araujo : Removed file: http://bugs.python.org/file22933/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: > >NO. I removed the 'copy_scripts' function, so I did not use your developed >functionality. After this change, Packaging module now just builds new-style >scripts and old-style scripts will be built by distutils/setuptools. To >

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: There are two kinds of configuration files supported in Packaging, and you can say it maybe a transition consideration from  distutils/setuptools to Packaging, but if you look into the documents of Packaging(you can generate it from the /Doc directory), you will

[issue12394] packaging: generate scripts from callable (dotted paths)

higery added the comment: >>BTW higery, did you use any of the build-scripts functionality I developed in >>the pythonv branch? NO. I removed the 'copy_scripts' function, so I did not use your developed functionality. After this change, Packaging module now just builds new-style scripts and

[issue12394] packaging: generate scripts from callable (dotted paths)

higery added the comment: >>IIUC the support for setup.py is transitional, i.e. "legacy support", for >>existing packages transitioning from distutils/setuptools/Distribute to >>packaging. New features should not rely on the existence of setup.py. I know, the implementation way of scripts has

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: BTW higery, did you use any of the build-scripts functionality I developed in the pythonv branch? Ref. https://bitbucket.org/vinay.sajip/pythonv/changeset/d2453f281baf -- ___ Python tracker

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: IIUC the support for setup.py is transitional, i.e. "legacy support", for existing packages transitioning from distutils/setuptools/Distribute to packaging. New features should not rely on the existence of setup.py. -- __

[issue12394] packaging: generate scripts from callable (dotted paths)

higery added the comment: Current patch has removed old-style scripts support and just retain new-style wrapper scripts generation support. Now, it uses only dotted path string to support kind of 'console_scripts' of setuptools, and uses dotted path with a 'window' or 'win' option to support

[issue12394] packaging: generate scripts from callable (dotted paths)

Changes by higery : Added file: http://bugs.python.org/file22922/4be1917b2a9e.diff ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: Your tests contain this: +sys.path.append(source) When using regrtest (see http://docs.python.org/devguide/runtests#running), you’ll get a warning that test_packaging altered sys.path. Your code should make sure sys.path is restored to its previous tes

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: higery’s message was this: > I have already set the option as you said earlier, but how to > 'push' it to remote repository? It's just a configuration file under > the .hg directory... I was mistaken; setting the diff git option is important if you generate patc

[issue12394] packaging: generate scripts from callable (dotted paths)

Changes by Éric Araujo : Removed file: http://bugs.python.org/file22744/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue12394] packaging: generate scripts from callable (dotted paths)

higery added the comment: remote repository? It's just a configuration file under the .hg directory... -- Added file: http://bugs.python.org/file22744/unnamed ___ Python tracker ___

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: You haven’t set the git option for the diff commands in your config file. -- ___ Python tracker ___ __

[issue12394] packaging: generate scripts from callable (dotted paths)

Changes by higery : Added file: http://bugs.python.org/file22727/c5692393c621.diff ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue12394] packaging: generate scripts from callable (dotted paths)

higery added the comment: >>Your test should catch stdout (see other packaging tests for how to do that), >>so that people or buildbots running the tests don’t see “Hello world!”, and >>so that you can run asserts for the output. Thanks. Got it - captured_stdout --

[issue12394] packaging: generate scripts from callable (dotted paths)

higery added the comment: >>The object with the name executable or options is bytes, which you should >>explicitly convert to a string with decode. I also don’t like using >>locals(), but that’s a personal style thing. Thanks for your test, I'll amend it. -- ___

[issue12394] packaging: generate scripts from callable (dotted paths)

higery added the comment: >>An octal literal in 3.x is 0o755. Decimal 755 means 0o1363, which is not >>good :) Thank you for your reminding. The reason I made this mistake is that I'm not familiar with the right way to set permission code in Python3+ . -- __

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: I confirm fixing 0o755 makes the tests pass for me. Your code gives one warning: build_scripts.py:241: BytesWarning: str() on a bytes instance hdr = "#!%(executable)s%(options)s\n" % locals() The object with the name executable or options is bytes, which you sh

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: Same bug. I’ve added debug prints to find out the rights (UNIX permission system) of the files, and they’re very strange: --wxrw--wt (the read bit is missing, and the t is strange). It should be -rwxr-xr-x, like other programs. The bug is likely this change: -

[issue12394] packaging: generate scripts from callable (dotted paths)

higery added the comment: >>IOError: [Errno 13] Permission denied: >>'/tmp/user/1013/tmp2xp9qc/tmpwhzzmg/script1' I have added an 'ensure_directory()' function to build_script.py, but I'm not sure if it can fix this error. -- ___ Python tracker <

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: > I think you did not get the latest version of my code. I pulled and updated again and got a different error :) ERROR: test_install_wrapper_scripts (packaging.tests.test_command_build_scripts.BuildScriptsTestCase)

[issue12394] packaging: generate scripts from callable (dotted paths)

higery added the comment: >>In your Mercurial configuration file, you should set the git option so that >>diffs can display editions to binary files. See >>http://hgtip.com/tips/beginner/2009-10-22-always-use-git-diffs/ Thanks. >>The new scripts feature should reuse the already existing scr

[issue12394] packaging: generate scripts from callable (dotted paths)

higery added the comment: >>packaging.errors.PackagingOptionError: your specific entry >>'script1=foo.bar.main1.main' does not exist! I think you did not get the latest version of my code. -- ___ Python tracker

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: Failure on POSIX (linux2): ERROR: test_install_wrapper_scripts (packaging.tests.test_command_build_scripts.BuildScriptsTestCase) -- Traceback (most recent call last): File "Lib/packaging/tests/

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: Great to hear these news! I will pull from your clone and test on linux2 as soon as possible. In your Mercurial configuration file, you should set the git option so that diffs can display editions to binary files. See http://hgtip.com/tips/beginner/2009-10-22

[issue12394] packaging: generate scripts from callable (dotted paths)

higery added the comment: I hope people can help me test this patch especially on non-Windows platforms. The main implementation resides in build_scripts.py. Usage: Just add a 'wrapper-scripts-entries' variable in setup.cfg, which takes a list type as its value. For instance, wrapper-scripts

[issue12394] packaging: generate scripts from callable (dotted paths)

Changes by higery : -- keywords: +patch Added file: http://bugs.python.org/file22711/6382acfb1685.diff ___ Python tracker ___ ___ Pyth

[issue12394] packaging: generate scripts from callable (dotted paths)

Changes by Éric Araujo : -- hgrepos: +42 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: > If the code is compatible with 2.6+ only, the “2.5” Trove classifier should > not be used. (Maybe I’m misunderstanding your point.) I was referring to your comment about the X in X.Y.Z. We also need to bear in mind that you sometimes just get trove classifier

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: > Perhaps some mechanism needs to be provided to indicate additional > processing options per script line: Sure. Higery will have to examine existing usage and think about setuptools→packaging transition. We’ll start simple and easy (in other words, with somet

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: > Version independence always means version independence in the same > major line of development (i.e. X number in X.Y.Z), or to put it > another way, version independence among the versions listed as > supported in the Trove classifiers. That can still be a probl

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: > In the setup.cfg files, scripts will now be a mapping of names to > callables, like the setuptools scripts and gui_scripts entry points: > > scripts = > sphinx-build = sphinx.build.run > On UNIX, a Python script named sphinx-build will be created, on > Windo

[issue12394] packaging: generate scripts from callable (dotted paths)

Changes by Per Cederqvist : -- nosy: +ceder ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: [Vinay] > I don't see how it makes sense to aim for version independence, > especially since 2.x and 3.x can each raise SyntaxErrors when > presented with the other's code. Version independence always means version independence in the same major line of developmen

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: > Fred L. Drake, Jr. added the comment: > > People working on this should probably also look at how zc.buildout's >zc.recipe.egg handles script generation. It's similar to setuptools in that >"console_script" entry points are used, but it binds in the des

[issue12394] packaging: generate scripts from callable (dotted paths)

Vinay Sajip added the comment: > Short review of the superseded bugs. > > #870479 — Scripts need platform-dependent handling > A request to remove .py on POSIX and create a .cmd file on Windows. The > .cmd >part was quickly shot down (see bug thread for problems), and the discussion >mov

[issue12394] packaging: generate scripts from callable (dotted paths)

Fred L. Drake, Jr. added the comment: People working on this should probably also look at how zc.buildout's zc.recipe.egg handles script generation. It's similar to setuptools in that "console_script" entry points are used, but it binds in the desired Python executable as well. (If you ran

[issue12394] packaging: generate scripts from callable (dotted paths)

Éric Araujo added the comment: Short review of the superseded bugs. #870479 — Scripts need platform-dependent handling A request to remove .py on POSIX and create a .cmd file on Windows. The .cmd part was quickly shot down (see bug thread for problems), and the discussion moved to the setupt

[issue12394] packaging: generate scripts from callable (dotted paths)

Changes by Éric Araujo : -- assignee: tarek -> eric.araujo nosy: +higery stage: -> needs patch title: Packaging should provide better support for executable scripts on Windows -> packaging: generate scripts from callable (dotted paths) ___ Python tr